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

概述: 開放授權協議

作用: 允許第三方應用訪問服務提供方中注冊的終端用戶的部分資源
下面是官方描述: [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) => 第三方應用

Resource Owner(User) => 用戶

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

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

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

(步驟 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在用戶授權后重定向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

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

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

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

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

OAuth 2.0定義了四種授權方式。

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

簡化模式（implicit）

密碼模式（resource owner password credentials）

客戶端模式（client credentials）

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

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

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

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

[RFC 對state參數的解釋]
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).
我們假設出現下面的場景:
（1）用戶甲到第三方網站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，授權該應用。
（5）授權服務器根據傳遞的redirect_uri參數，組合認證參數code生成地址c：
http://aaa.comindex.php&code=【809ui0asduve】
（6）用戶甲瀏覽器返回到地址c,完成綁定
此時即使我們交換兩個用戶的地址c,則會出現綁定錯誤的情況,避免出現該情況的辦法就是對state參數進行驗證,來判斷該state參數是否是該用戶所對應的重定向地址

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 的之間的區別有哪些？》

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

http://blog.sina.com.cn/s/blo... 《小議OAuth 2.0的state參數——從開發角度也說《互聯網最大規模帳號劫持漏洞即將引爆》》

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

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