OAuth 流程與發(fā)展總結(jié) (1.0 => 1.0a => 2.0)

adie 發(fā)布于2019-08-22 15:42 / 3433人閱讀

摘要：如果不使用回調(diào)地址桌面或手機程序，而是通過手動拷貝粘貼完成授權(quán)的話，那么只要攻擊者在在前面發(fā)起請求，就能拿到的。改進步驟傳遞參數(shù)而不是獲取已授權(quán)步驟申請時，必須傳遞讓參與簽名避免攻擊者假冒。

OAuth 流程與發(fā)展 (1.0 => 1.0a => 2.0) 概述

概述: 開放授權(quán)協(xié)議

作用: 允許第三方應(yīng)用訪問服務(wù)提供方中注冊的終端用戶的部分資源
下面是官方描述: [OAuth描述] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

參與者:

Client (Consumer) => 第三方應(yīng)用

Resource Owner(User) => 用戶

Resource Server(Service Provider) => 資源服務(wù)提供方(OAuth2.0將服務(wù)提供方拆分為兩部分)

Authorization Server(Service Provider) => 授權(quán)服務(wù)提供方(OAuth2.0將服務(wù)提供方拆分為兩部分)

OpenID (WHO) 和 OAuth (WHAT)
=> OpenID 更加關(guān)注 "我是誰" 的問題
=> OAuth 更加關(guān)注 "我能獲得哪些權(quán)限的問題"

OAuth1.0 流程圖

接口

(步驟 A) Consumer申請Request Token（/oauth/1.0/request_token）：
oauth_consumer_key
oauth_signature_method
oauth_signature
oauth_timestamp
oauth_nonce
oauth_version

(步驟 B) Service Provider返回Request Token：
oauth_token
oauth_token_secret

(步驟 C) Consumer重定向User到Service Provider（/oauth/1.0/authorize）：
oauth_token
oauth_callback

(步驟 D) Service Provider在用戶授權(quán)后重定向User到Consumer：
oauth_token

(步驟 E) Consumer申請Access Token（/oauth/1.0/access_token）：
oauth_consumer_key
oauth_token
oauth_signature_method
oauth_signature
oauth_timestamp
oauth_nonceoauth_version

(步驟 F) Service Provider返回Access Token：
oauth_token
oauth_token_secret

OAuth1.0 漏洞 兩種Token，分別是Request Token和Access Token，其中Request Token又涉及兩種狀態(tài)，分別是未授權(quán)和已授權(quán)。 攻擊者會先申請攻擊者自己的Request Token，然后誘使用戶授權(quán)這個攻擊者的Request Token，接著針對回調(diào)地址的使用，又存在以下幾種攻擊手段：

如果Service Provider沒有限制回調(diào)地址（應(yīng)用設(shè)置沒有限定根域名一致），那么攻擊者可以把oauth_callback設(shè)置成成自己的URL。

如果Consumer不使用回調(diào)地址（桌面或手機程序），而是通過User手動拷貝粘貼Request Token完成授權(quán)的話，那么只要攻擊者在在User前面發(fā)起請求，就能拿到User的Access Token。

OAuth1.0 改進

步驟 B 傳遞 callback_url參數(shù) (而不是獲取已授權(quán) request_token 步驟) Consumer申請Request Token時，必須傳遞oauth_callback, 讓callback參與簽名, 避免攻擊者假冒callback。

驗證完未授權(quán) request_token 返回新的參數(shù) oauth_verifier 驗證完成后會返回驗證碼(oauth_verifier)在沒有callback的時候, 服務(wù)提供方顯示給用戶，然后用戶可以在第三方應(yīng)用的設(shè)備上輸入，標(biāo)示自己已經(jīng)授權(quán)（和未授權(quán)的用戶分開），然后第三方應(yīng)用必須加上該驗證碼去獲取

OAuth1.0a 流程圖

OAuth2.0 流程

OAuth 2.0定義了四種授權(quán)方式。

授權(quán)碼模式（authorization code）(本文只講解該授權(quán)方式)

簡化模式（implicit）

密碼模式（resource owner password credentials）

客戶端模式（client credentials）

接口

(步驟 A) Client 向Authorization Server發(fā)出申請（/oauth/2.0/authorize）：
response_type = code?client_id?redirect_uri?scope?state

(步驟 B) Authorization Server 在Resource Owner授權(quán)后給Client返回
code?state

(步驟 C) Client向Authorization Server發(fā)出申請（/oauth/2.0/token）：
grant_type = authorization_code?code?client_id?client_secrect?redirect_uri

(步驟 E) Server在Resource Owner授權(quán)后給Client返回Access Token：
access_token?token_type?expires_in?refresh_token

關(guān)于 state 參數(shù)

[RFC 對state參數(shù)的解釋]
The authorization server SHOULD require the client to provide the complete redirection URI (the client MAY use the "state" request parameter to achieve per-request customization). If requiring the registration of the complete redirection URI is not possible, the authorization server SHOULD require the registration of the URIscheme, authority, and path (allowing the client to dynamically vary only the query component of the redirection URI when requesting authorization).
我們假設(shè)出現(xiàn)下面的場景:
（1）用戶甲到第三方網(wǎng)站A登錄后，到了綁定頁面。此時還沒綁定微博。
（2）綁定頁面提供一個按鈕：“綁定微博”（地址a：http://aaa.com/index.php?m=us...）
（3）用戶甲點擊地址a，程序生成如下地址b：
https://api.weibo.com/oauth2/...【9999999】&redirect_uri=【http://aaa.comindex.php】&response_type=【code】
（4）用戶甲瀏覽器定向到地址b，授權(quán)該應(yīng)用。
（5）授權(quán)服務(wù)器根據(jù)傳遞的redirect_uri參數(shù)，組合認證參數(shù)code生成地址c：
http://aaa.comindex.php&code=【809ui0asduve】
（6）用戶甲瀏覽器返回到地址c,完成綁定
此時即使我們交換兩個用戶的地址c,則會出現(xiàn)綁定錯誤的情況,避免出現(xiàn)該情況的辦法就是對state參數(shù)進行驗證,來判斷該state參數(shù)是否是該用戶所對應(yīng)的重定向地址

參考文獻

https://huoding.com/2010/10/10/8 《OAuth那些事兒》

https://huoding.com/2011/11/0... 《OAuth的改變》

https://www.zhihu.com/questio...《Oauth 1.0 1.0a 和 2.0 的之間的區(qū)別有哪些？》

http://www.ruanyifeng.com/blo... 《理解 OAuth2.0》

http://blog.sina.com.cn/s/blo... 《小議OAuth 2.0的state參數(shù)——從開發(fā)角度也說《互聯(lián)網(wǎng)最大規(guī)模帳號劫持漏洞即將引爆》》

https://tools.ietf.org/html/r... 《RFC 6749》

結(jié)語

這篇文章是參考網(wǎng)上的資料的總結(jié), 如果有錯誤歡迎批評指正, 如果侵權(quán), 請作者聯(lián)系我刪除文章, 謝謝
有興趣的同學(xué)也可以參照 [微博OAuth] API, 申請一個第三方應(yīng)用, 參照微博API去實現(xiàn)一個獲取 access_token的測試用例 (微博會給予申請的第三方應(yīng)用 client_id, client_secret)