大話Oauth2.0(二)、標準流程下的Oauth2組件及通信

首先祝大家五一節日快樂！

Oauth2.0協議的核心內容是，第三方軟件如何獲取訪問令牌，以及如何利用這個訪問令牌代表資源擁有者訪問受保護的資源。在這篇文章中我們從Oauth2的組件和組件間的通訊講起。

1、Oauth2組件

一個標準的Oauth2.0共包含四個組件，如下圖所示，分別是資源擁有者、第三方軟件、授權服務、資源服務。資源擁有者是Oauth2流程的發起者，也是第三方軟件的使用者；第三方軟件，在Oauth2裏面官方的名稱叫做客戶端，現實世界中其實就是平臺之外的第三方軟件；授權服務，提供授權碼、訪問令牌；資源服務，提供WEB API以便接收第三方軟件的訪問請求。授權服務和資源服務都是平臺（比如微信開放平臺、淘寶開放平臺、京東開放平臺等）一方提供的服務。

目前這四個組件暫時沒有發生任何通信，僅僅是展示了重要的四個Oauth2組件而已。這篇文章我們要描述的是標準的Oauth2流程，之所以稱爲標準的流程，也是Oauth2的規範性流程，這個流程中包含了授權碼和訪問TOKEN。這個規範性的流程規定了要通過兩次URI重定向。爲什麼要通過URI重定向？而且爲什麼需要兩次？接下來我們會去詳細分析解答。

2、Oauth2通信

2.1、第三方軟件和授權服務之間的通信

Oauth的最原始背景就是解決WEB應用下的授權的安全問題，因此一定不能缺少瀏覽器的參與。對於非標準條件下的Oauth流程在後續的文章中我們也會有講述，那個時候可能有的場景是不需要瀏覽器的。現在我們在敘述的是標準場景下的Oauth使用。

Oauth組件間的通信包括前端通信和後端通信，前端通信就是組件之間的需要交互的信息數據在瀏覽器裏面流轉，後端通信就是組件之間需要交互的數據信息通過WEB SERVER之間流轉。實際上只有標準場景下的Oauth2流程纔會既使用前端通信又使用後端通信，這點在介紹非標準場景下的Oauth使用的時候也會去分析，大家先記下來。

資源所有者A要授權正在使用的第三方軟件來能夠訪問A在平臺上受保護的資源，那麼A通過瀏覽器首先訪問的是第三方軟件的URI地址，此時第三方軟件遵循Oauth2.0的協議並按照平臺的要求拼接授權URL(參照大話Oauth2.0(一)從概念到實踐)，將用戶引導到平臺的授權頁面，這個時候發生了第一次URI重定向。A點擊了授權頁面上的授權按鈕，平臺一方的授權服務器會對當前的用戶進行身份驗證，如果身份合法會生成一個CODE也就是我們常說的授權碼，然後將這個CODE重定向回第三方軟件的CALLBACK URI上(這個CALLBACK URI是拼接授權URI的時候就傳過來了)，這個時候發生了第二次URI重定向。第一次重定向好理解，用戶在使用瀏覽器訪問第三方軟件的URI地址，第三方軟件需要做引導。第二次重定向爲什麼也需要呢，通過WEB SERVER直接OUT PRINT回第三方軟件的服務器不就可以了嗎，如果僅僅是返回這個CODE值當然可以，而且這樣還更安全。但是不要忘記了用戶還在瀏覽器上面等着呢，如果將CODE的值直接寫回到第三方軟件的WEB SERVER上，就會把瀏覽器上的用戶旁路了，因此還必須進行第二次重定向。至此獲取CODE的流程都是通過前端通信進行交互的。

在第三方軟件獲取到CODE之後，同樣遵循Oauth2.0的協議並按照平臺的要求，會發起一個HTTP POST請求到授權服務器，去訪獲取ACCESS TOKEN（訪問令牌），這個HTTP請求中包含了平臺一方事先給第三方軟件分配好的client_id和client_secret，這樣ACCESS TOKEN的數據傳遞就是在兩個WEB SERVER之間的交互了。至此獲取訪問令牌的流程是通過後端通信進行交互的，另外再加上HTTPS的保護，ACCESS TOKEN的獲取變得更安全了。

以上交互通信如下圖所示。

我們還會思考另外一個問題，爲什麼標準流程下需要先獲取CODE，然後再通過CODE獲取ACCESS TOKEN呢？這個原因可以結合前端通信環節中的必須經過兩次瀏覽器重定向的描述，如果沒有獲取CODE這個流程，直接將ACCESS TOKEN重定向回瀏覽器，無疑這會將訪問令牌暴露出去帶來安全上的問題。

2.2、第三方軟件和資源服務之間的通信

在第三方軟件獲取到訪問令牌之後通過WEB API的方式請求資源服務器，來訪問資源所有者的數據。請求的時候要帶上第三方軟件的client_id、client_secret和acces_token。資源服務器則需要判斷來訪的第三方軟件的合法性。同時還需要通過access_token去換取用戶的pin才能最終訪問到資源所有者的數據，因爲數據庫中的存儲記錄中是以pin的維度來存儲的。交互通信如下圖所示。

在這個階段內除了上面說的換取訪問令牌的通信，還有一種通信即刷新訪問令牌請求通信。後面會介紹到。

2.3、資源服務和授權服務之間的通信

資源服務器和授權服務器之間通信的目的就是要通過access_token換取pin。實現這個目的可以讓兩個服務共享一個數據存儲，也可以讓授權服務器提供一個RPC接口供資源服務器來調用。交互通信如下圖所示。

3、標準Oauth2下的第三方軟件請求參數列表

3.1、獲取CODE需要的請求參數

名稱	是否必填	參數值
client_id	是	第三方軟件的平臺唯一標識，相當於ID
redirect_uri	是	第三方軟件的平臺的祕鑰，相當於密碼
response_type	是	code
state	否	一個隨機值，要求發送和平臺返回的值必須一致

注：state雖然不是必填參數，但是建議要有，它關乎跨站防護的安全問題，state的用法在後續關於Oauth2的安全文章中會重點介紹。

3.2、通過CODE獲取ACCESSTOKEN的請求參數

名稱	是否必填	參數值
client_id	是	第三方軟件的平臺唯一標識，相當於ID
client_secret	是	第三方軟件的平臺的祕鑰，相當於密碼
grant_type	是	authorization_code
code	是	code
redirect_uri	是	重定向URI，第三方軟件的系統地址

4、標準Oauth2下的平臺端響應參數列表

名稱	說明
access_token	訪問令牌
token_type	目前access_token的類型只支持bearer類型
expires_in	access_token的過期時間
refresh_token	用於重新獲取access_token的值

如果access_token訪問令牌過期了該怎麼辦，讓用戶再重新授權一次？這樣的話體驗會很差，access_token設置失效時間本身是爲了安全性，有沒有既能保證安全有不損害用戶體驗的方法，Oauth2.0提供了一種無須用戶參與的情況下獲取訪問令牌的方法，就是refresh_token機制。比如用戶購買了第三方軟件時間週期爲1年，那麼在這1年之內，access_token會10天過期一次，這個時候就需要第三方軟件利用refresh_token重新獲取新的access_token來繼續請求受保護的資源，這樣則不需要用戶重新授權，不然10天授權一次就是一個很糟糕的體驗。