資源受權？對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格式：

格式：https://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文章

1.OAuth2.0協議標準

2.大神阮一峯的文章：OAuth2.0的四種方式