OAuth2.0-授權碼模式解析

前言

OAuth 2.0是行業標準的授權協議。 OAuth 2.0取代了2006年創建的原始OAuth協議所做的工作。它專注於客戶端開發人員的簡單性，同時爲Web應用程序，桌面應用程序，移動電話和客廳設備提供特定的授權流程。該規範及其擴展正在IETF OAuth工作組內開發。

授權碼模式流程解析

在Oauth2.0授權碼模式中會涉及以下幾個角色，我們分別授予他們具體的場景解釋：

Client：指應用程序（可以理解爲任意支持微信登陸的程序，這裏我們以熊貓TV爲列）

Resource Owner：程序的用戶（我是微信的用戶）

Authorization Server：授權服務器（服務方微信的授權服務器）

Resource Server：資源服務器（服務方微信的資源服務器）

User-Agent：瀏覽器（用來跳轉服務器微信開發的用戶授權頁面）

我們按照圖中的流傳遞編號分析授權碼模式的過程：

A：在應用程序中選擇微信登陸，此時應用程序會請求用戶授權登陸頁面（這是微信的用戶授權頁面），在跳轉的過程中

會打開瀏覽器並攜帶如下參數：

https://authorization-server.com/auth
 ?response_type=code
 &client_id=29352915982374239857
 &redirect_uri=https%3A%2F%2Fexample-app.com%2Fcallback
 &scope=create+delete
 &state=xcoiv98y2kd22vusuye3kch

• response_type：告訴授權服務器（微信）這是授權碼模式
• clien_id：第三方應用程序（熊貓TV）的客戶端標識符（client_id和client_secret等信息在熊貓TV向微信平臺註冊時會獲得）
• redirect_uri：第三方應用程序的地址，告訴授權服務器（微信）在批准請求後應該將用戶等信息返回的位置。（這個uri是應用程序自己配置的，微信授權完成後人家得知道授權結果該發到哪）
• scope：這是一個或多個空格分隔的字符串，指示第三方應用程序請求的權限。
• state：第三應用程序隨機生成的字符串，state在傳給授權服務器之後，授權服務器在授權完成後會將該state返回給第三方應用程序。第三方程序接收到授權服務器（微信）返回的state後會和當初發送的state進行對比判斷兩個值是否相等。（主要用戶防防止CSRF攻擊）

B：用戶看到《用戶授權頁面》並選擇【授權】或者【拒絕授權】

C：假設用戶選擇【授權】，並且第三方程序發送的請求參數都正確（A流中傳遞過來的參數）。授權服務器（微信）經過一系列校驗後通過後會生成一個Authorization code（授權碼）同時會通過redierct_uri返回如下參數：

https://example-app.com/redirect
 ?code=g0ZGZmNjVmOWIjNTk2NTk4ZTYyZGI3
 &state=xcoiv98y2kd22vusuye3kch

• state：第三方應用程序請求時發送的state，狀態值與第三方應用程序最初在請求中設置的值相同。
• authorization code：授權服務器（微信）產生的code，它的有效期通常爲1～10分鐘。（有效期在授權服務器設置）

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------美麗的分割線，以下步驟將對用戶不可見---------------------------------------------------------------------------------------------第三方程序收到authorization code會用其換取access_token--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

D：第三方應用程序已經接收到授權服務器產生的authorization code，並且校驗返回的state和請求state的一致性，確認authorization code是當初發出的請求對應返回的授權碼。確認無誤後第三方應用程序會再次向授權服務器發送請求（這次是Post請求）。這次請求的目的是用authorization code換取access_token，請求的參數如下：

• grant_type：告訴token point第三方用戶程序正在使用授權碼模式
• authorization_code：從授權服務器（微信）獲取到的授權碼
• redirect_uri：和A步驟傳遞的值一樣，同樣是爲了告訴授權服務器服務器在授權完成後將授權結果發送到哪（這個參數不是必須的，使用的時候需要仔細查看所調用的API是否要求了傳遞該參數）
• client_id：第三方應用程序的標識符
• client_secret：第三方應用程序的密鑰（這是爲了確保獲取access_token的請求來自第三方應用程序，而不是來自某個劫取authorization code的危險者的請求）

E：授權服務器（微信）接收到請求並完成校驗，通過後會想redirect_uri返回如下參數：

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
  "scope":"create delete"
}

本文分析了Oauth2.0授權碼模式的原理和流傳遞間的參數，在閱讀過程中如果您有任何疑問和建議歡迎留言探討。

參考文獻：

https://tools.ietf.org/html/rfc6749 

https://developer.okta.com/blog/2018/04/10/oauth-authorization-code-grant-type