資源授權？對OAuth2.0的一次重新認識的過程
什麼是OAuth？
OAuth一個開放的授權標準，允許用戶在不提供關鍵資訊（如帳號，密碼）給第三方應用的前提下，讓第三方應用去訪問用戶在某網站上的資源（如頭像，用戶昵稱等）。
OAuth分為OAuth1.0和OAuth2.0兩個版本，後來隨著OAuth2.0被使用的越來越廣泛，OAuth1.0逐漸退出舞台（當然仍有少部分系統在使用1.0授權標準）。下面我們圍繞OAuth2進行展開。
OAuth 2.0致力於簡化客戶端開發人員的工作，同時為Web應用程式，桌面應用程式，行動電話和客廳設備提供特定的授權流程。
我們以部落格園登錄為例：
新同學小明想在「部落格園」發表文章，這時候他進入登錄頁面，「部落格園」登錄首頁需要小明提供用戶名和密碼才允許小明登入。
而由於小明是第一次使用「部落格園」，他對部落格園可能不是很信任，於是他想通過下方的他信任QQ應用直接登錄。
來到這裡我們發現，通過授權，「部落格園」將獲得小明在QQ應用中的資源（昵稱，頭像，性別），並成功登錄「部落格園」，而並不需要提供用戶名和密碼給「部落格園」。
上例中「部落格園」就是所謂的第三方應用，而QQ就是提供受保護資源的某個應用。
OAuth2四個參與角色
1.資源所有者（Resource Owner）：資源的擁有者（上例中：小明）
2.資源伺服器（Resource Server）：資源所在的伺服器（上例中：QQ應用）
3.授權伺服器（Authorization Server）：用於驗證client（第三方應用）的真實性，提供授權碼和令牌token。授權伺服器可單獨部署，也可以和資源伺服器一起部署。
4.第三方應用（Client）：訪問受保護資源的客戶端，上例中：部落格園
這裡，很多同學會對「授權伺服器」存在疑惑，上例中部落格園登錄流程並未體現授權伺服器啊？我們接著往下看
OAuth2標準授權流程
結合OAuth2經典流程圖，我們一下再來看下小明登錄「部落格園」的流程。
（A）第三方應用（client）「部落格園」向（資源擁有者）小明發起授權請求，即小明點擊部落格園登錄頁中的QQ登錄。
（B）QQ登錄授權頁面，小明登錄自己的QQ帳號，同意授權給「部落格園」，並返回授權許可憑證。
（C）第三方應用（client）「部落格園」拿著步驟（B）獲取的授權許可憑證，向授權伺服器發起請求。
（D）授權伺服器同意第三方應用（client）「部落格園」的請求，並返回一個令牌Token。
（E）第三方應用（client）「部落格園」拿著Token請求（資源伺服器）QQ應用中的昵稱，頭像等資源
（F）（資源伺服器）QQ應用驗證Token通過，並返回資源給第三方應用（client）「部落格園」
通過上述流程，我們可以看出，當QQ授權同意後，並不是馬上就將QQ應用中的資源返回給第三方客戶端的，而是需要客戶端拿著授權許可憑證，向授權伺服器請求並獲取最終的鑰匙Token，然後才能獲得受保護資源。
顯然，授權伺服器充當了一個驗證client，並頒發token令牌的服務角色。
那麼授權許可憑證到底是什麼呢？
OAuth2授權許可憑證
1.授權碼（Authorization Code）：
該模式目前是功能最完整、流程最嚴密的授權模式。一般需要client有專門的後端server，根據獲取的授權碼code在後端server請求令牌token。
上例中部落格園登錄授權就是用的「授權碼模式」，交互流程如下：
1）部落格園向小明發起QQ授權請求。 2）QQ授權驗證同意後，根據部落格園提供的Redirect_url返回，並帶上授權碼code 3）部落格園前端根據返回的url獲取授權碼code，並在後端server向授權伺服器發起請求獲取token 4）授權服務驗證通過，並以json格式返回token 5）部落格園再根據token請求QQ應用中獲取受保護資源（頭像，昵稱等）
步驟(1)，授權請求（Authorization Request）：
client需提供如下主要參數：
1.client_id：必填，第三方應用唯一標識ID 2.redirect_uri：必填，授權同意後，重定向地址URL 3.response_type：必填，授權碼模式下固定值為「code」 4.state：選填，一個狀態碼，可用於防止跨站請求偽造（CSRF）攻擊。客戶端發起授權請求時會生成一個狀態碼與客戶端綁定，授權請求成功後會將該state原樣返回 5.scope：選填，標識授權範圍
例如部落格園向QQ發起授權請求：
https://graph.qq.com/oauth2.0/show?which=Login&display=pc
&client_id=101880508
&scope=get_user_info
&response_type=code
&redirect_uri=***
&state=*****
擴展：跨站請求偽造（CSRF）攻擊：用戶登錄了A可信網站，認證資訊保存在瀏覽器cookie中。當用戶訪問攻擊者創建的B網站時，用戶認證資訊仍有效，攻擊者通過在B網站發送一個偽造的請求提交到A網站伺服器上，讓A網站伺服器誤以為請求來自於自己的網站。
步驟(2)，授權請求同意後，返回資訊：
1.code：授權碼 2.state：原樣返回，client提交的state狀態碼
步驟(3)，根據授權碼code，後端請求token，client需提供如下參數
1.grant_type：必填。授權碼模式，固定值「authorization_code」。 2.code : 必填。授權同意後返回的授權碼。 3.redirect_uri：必填。授權同意後，重定向地址URL
4.client_id：必填。第三方應用唯一標識ID。
5.client_secret：必填。第三方應用授權申請的秘鑰。
例如：
POST /oauth/token HTTP/1.1 Host: authorization-server.com grant_type=authorization_code &code=xxxxxxxxxxx &redirect_uri=https://example-app.com/redirect &client_id=xxxxxxxxxx &client_secret=xxxxxxxxxx
步驟(4)，授權認證通過，返回主要參數。
1.access_token：訪問令牌。 2.refresh_token：刷新令牌。 3.expires_in：令牌過期時間。
4.token_type：令牌類型。
其中刷新令牌refresh_token的作用是，當訪問令牌token失效時，無需重新發起授權獲取新的token,根據刷新令牌直接請求授權服務，就可以獲取新的令牌。
2.隱式許可(Implicit)：
授權碼模式的簡化應用，跳過了獲取授權碼code的過程，直接獲取token。一般用於沒有後端的Client。
如果部落格園使用該模式，其工作流程：
1）部落格園向小明發起QQ授權請求。 2）QQ授權驗證同意後，根據部落格園提供的Redirect_url返回，並帶上令牌token
3）部落格園再根據token請求QQ應用中獲取受保護資源（頭像，昵稱等）
步驟（1），授權請求參數和授權碼模式參數一樣，唯一不同的參數是response_type，Implicit模式下固定值為「token」。
步驟（2），授權請求同意後，返回資訊：
1.access_token：訪問令牌。
2.token_type：令牌類型。
3.expires_in：令牌過期時間。
註：隱式授權模式頒發的令牌，不提供refresh刷新令牌
URL格式：
格式：//a.com/callback#token=ACCESS_TOKEN
注意，令牌的位置是 URL 錨點「#」後面，而不是查詢字元串「?」後面，這是因為 OAuth2允許跳轉網址是 HTTP 協議，因此存在”中間人攻擊”的風險，而瀏覽器跳轉時，錨點不會發到伺服器，就減少了泄漏令牌的風險。
3.用戶密碼模式(Resource Owner Password Credentials)：
客戶端提供用戶名和密碼，獲取token。前面我們說OAuth2就是為了避免直接提供用戶名和密碼給第三方應用程式而誕生，那麼這裡又是怎麼回事呢？
其實，該授權模式的初衷是為服務自己的應用啟用密碼登錄，用戶使用其用戶名和密碼登錄該服務的網站或本機應用程式，但是絕對不允許第三方應用程式詢問用戶密碼。
授權請求，提供參數：
1.grant_type：必填。該模式下固定值為「password」。 2.username：必填。用戶登陸名。 3.passward：必填。用戶登陸密碼。 4.scope：可填。表示授權範圍。
5.客戶端認證參數：通常如果授權服務管理系統給客戶端頒發了身份秘鑰資訊（client_id,client_secret）,那麼客戶端發起授權請求時需要攜帶參數client_id和client_secret。或在HTTP Basic auth標頭中接受客戶端client_secret和密碼client_secret
其中，客戶端認證參數：client_id和client_secret主要是用於授權服務驗證客戶端的身份。如果客戶端都沒在授權服務管理系統備案（不需要驗證客戶端身份），那麼授權請求就不需要這兩個參數。備案又是什麼呢？大家請留意文章末尾。
以postman請求token為例：
第一種方式：將client_id和client_secret作為請求體參數
第二種方式：在HTTP Basic auth請求頭中單獨驗證client_secret和client_secret
授權請求同意後，返回主要參數：
1.access_token：訪問令牌。 2.token_type：令牌類型。 3.expires_in：令牌過期時間。 4.scope：授權範圍
4.客戶端模式(Client Credentials)：
當第三方應用程式請求訪問令牌以訪問其自己的資源（而非代表其他用戶去訪問資源）時，使用該模式。此時第三方應用程式將自己當成資源所有者，直接請求授權伺服器獲取令牌token。
授權請求，提供參數：
1.grant_type：必填。該模式下固定值為「client_credentials」。
2.scope：可填。表示授權範圍。
3.客戶端認證：必填，包含參數client_id和client_secret；或在HTTP Basic auth標頭中接受客戶端client_secret和密碼client_secret
以postman請求token為例：
第一種方式：將client_id和client_secret作為請求體參數
第二種方式：在HTTP Basic auth請求頭中單獨驗證client_secret和client_secret
兩種方式效果一致，都是通過client_id和client_secret，讓授權伺服器驗證客戶端的身份。
授權請求同意後，返回參數：
1.access_token：訪問令牌。
2.token_type：令牌類型。
3.expires_in：令牌過期時間。
4.scope：授權範圍
擴展：第三方應用發起授權請求時，client_id和client_secret是哪來的呢？
授權服務提供第三方應用的管理：
第三方應用申請令牌之前，都必須先到授權服務系統備案，說明自己的身份，然後會拿到兩個身份識別碼：客戶端 ID（client ID）和客戶端密鑰（client secret）。這是為了防止令牌被濫用，沒有備案過的第三方應用，是不會拿到令牌的。
5.刷新令牌refresh token
前面我們說，當授權請求同意後，通常授權伺服器會返回一個刷新令牌refresh token給我們（該返回參數非必選的，由授權服務訂製，通常推薦返回該參數）。
當訪問令牌access token 過期後，如果重新發起一遍請求令牌的過程顯然有點麻煩，這時候通過refresh token發起一次請求可以直接獲取新的訪問令牌access token。
請求參數：
1.grant_type：必填。固定值為「refresh_token」。 2.refresh_token：必填。 3.scope：可填。表示授權範圍。 4.客戶端認證：通常如果授權服務管理系統給客戶端頒發了身份秘鑰資訊（client_id,client_secret）,那麼客戶端發起授權請求時需要攜帶參數client_id和client_secret。或在HTTP Basic auth標頭中接受客戶端client_secret和密碼client_secret。
如果客戶端不需要身份認證，則無需攜帶任何身份認證的資訊
例如：
POST /oauth/token HTTP/1.1 Host: authorization-server.com grant_type=refresh_token &refresh_token=xxxxxxxxxxx &client_id=xxxxxxxxxx &client_secret=xxxxxxxxxx
本文，我們結合部落格園授權QQ登錄的案例，描述了OAuth2的基本概念，OAuth2的授權流程以及各種授權模式的使用。多動手，多動手，多動手才能加深自己的理解。
附：推薦幾篇值得學習的OAuth2文章
