原文章 作者：Aaron Parecki
譯者：MoCha => 摩卡先生
前言
授權(quán)碼模式大概是我們所最常見的OAuth 2.0 授權(quán)模式。當(dāng)用戶授權(quán)給App時，授權(quán)碼模式就會在網(wǎng)頁應(yīng)用和原生apps中使用到。
本文章是本系列文章中的第一部分，我們將探討常用的OAuth 2.0 授權(quán)模式。如果你想在我們深入之前了解更多有關(guān)OAuth 2.0的知識，請查看What the Heck is OAuth?，這篇文章同樣能夠在Okta開發(fā)者博客上找到。
What is an OAuth 2.0 Grant Type? 什么是 OAuth 2.0 授權(quán)模式？
在OAuth 2.0 標(biāo)準(zhǔn)中，“授權(quán)模式”指的是一種為應(yīng)用程序獲取access token的方式。
OAuth 2.0 定義了好幾種授權(quán)模式，其中包括“授權(quán)碼模式”。OAuth 2.0 的擴展同樣可以定義一些新的授權(quán)模式。
每一種授權(quán)模式在對應(yīng)的一些特殊用例中都有著最佳實踐，例如：web app，原生 app，一些無法啟動web瀏覽器的設(shè)備，或者是服務(wù)器端到服務(wù)器端的應(yīng)用程序。
The Authorization Code Flow 授權(quán)碼模式的流程
授權(quán)碼授權(quán)模式被用于web應(yīng)用以及手機app中。與大多數(shù)授權(quán)模式不同，授權(quán)碼模式會在一開始就請求應(yīng)用去啟動瀏覽器來進(jìn)行一系列操作。更深入點說，授權(quán)碼模式的流程有以下步驟：
- 應(yīng)用程序打開瀏覽器，將用戶連接到OAuth的服務(wù)端中
- 用戶會看到授權(quán)提示以及是否同意應(yīng)用的請求
- 用戶被重定向回到應(yīng)用程序中，同時在請求欄中攜帶著授權(quán)碼字符串
- 應(yīng)用程序為了獲取access token而進(jìn)行交換授權(quán)碼的操作
Get the User’s Permission 獲取用戶權(quán)限
OAuth 旨在讓用戶能夠授予應(yīng)用程序特定的受限訪問權(quán)限。應(yīng)用程序首先會確定需要請求的權(quán)限，之后會將用戶傳送至對應(yīng)的瀏覽器中以獲得他們的許可。為了開啟授權(quán)流程，應(yīng)用程序會構(gòu)造類似以下格式的URL，并且通過瀏覽器進(jìn)行訪問。
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
下面是有關(guān)請求參數(shù)的說明：
- response_type=code告訴授權(quán)服務(wù)器，應(yīng)用正在初始化授權(quán)流程
- client_id 應(yīng)用程序的公共標(biāo)識，將在開發(fā)者首次注冊應(yīng)用時獲得
- redirect_uri 告訴授權(quán)服務(wù)器當(dāng)用戶同意應(yīng)用的請求后應(yīng)該將用戶返回到何處
- scope 一個或多個以空格分隔的字符串，用于指示應(yīng)用程序請求的權(quán)限。在使用具體的OAuth API時，我們將指定所支持作用域。
- state 應(yīng)用程序?qū)⑸梢粋€隨機字符串并包含在請求中，我們應(yīng)該對用戶授權(quán)應(yīng)用程序后是否返回相同的值進(jìn)行檢查。這是為了防止 CSRF attacks.
當(dāng)用戶訪問此URL時，授權(quán)服務(wù)器會提示用戶，詢問他們是否要授權(quán)此應(yīng)用程序的請求。
Redirect Back to the Application 重定向回到應(yīng)用程序
如果用戶同意授權(quán)，那么授權(quán)服務(wù)器將重定向回到指定的redirect_uri ，并且攜帶著code以及state
例如，用戶將重定向回到以下URL：
https://example-app.com/redirect ?code=g0ZGZmNjVmOWIjNTk2NTk4ZTYyZGI3 &state=xcoiv98y2kd22vusuye3kch
state的值將會和應(yīng)用程序剛初始請求時設(shè)置的一樣。但應(yīng)用程序應(yīng)當(dāng)檢查重定向中的state是否與最初設(shè)置的state一致
code是通過授權(quán)服務(wù)器生成的授權(quán)碼，授權(quán)碼相對來說存活時間是短暫的，在依賴OAuth服務(wù)的情況下，一般存活在1~10分鐘。
Exchange the Authorization Code for an Access Token 為了獲取Access Token 進(jìn)行的授權(quán)碼交換
我們即將要結(jié)束授權(quán)的流程啦?，F(xiàn)在應(yīng)用程序有了授權(quán)碼，我們可以用它來獲取Access Token。
應(yīng)用程序?qū)ㄟ^以下步驟發(fā)起POST請求到服務(wù)令牌終端：
- grant_type=authorization_code 告訴令牌終端，應(yīng)用程序正在使用授權(quán)碼模式。
- code 重定向回來后，應(yīng)用程序所攜帶的授權(quán)碼。
- redirect_uri 與請求授權(quán)碼時設(shè)置的重定向URL一樣。有些API不需要該請求參數(shù)，所以在使用之前應(yīng)當(dāng)仔細(xì)查閱想要使用API的文檔。
- client_id 應(yīng)用程序的客戶端ID。
- client_secret 應(yīng)用程序的客戶端secret。確保獲取到access token是來自該應(yīng)用程序的，而不是那些有可能攔截授權(quán)碼的潛藏攻擊者。
令牌終端將驗證請求中的所有參數(shù)，確保授權(quán)碼不會過期以及客戶端ID和客戶端secret是匹配的。如果一切的檢查順利，沒有問題，那么將會生成一個access token響應(yīng)回去！
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"
}
這就是完整的授權(quán)流程啦！現(xiàn)在應(yīng)用程序有了access token，那么就可以調(diào)用相關(guān)API進(jìn)行請求啦。
When to use the Authorization Code Flow 什么時候該使用授權(quán)碼
在使用web應(yīng)用或者是手機應(yīng)用中，授權(quán)碼模式將是最好的選擇。由于授權(quán)碼模式在獲取access token上額外進(jìn)行了交換授權(quán)碼的步驟，因此提供了一種隱式授權(quán)模式所沒有的安全層。
如果你正在手機應(yīng)用上使用授權(quán)碼模式，或者無法存儲客戶端secret的其他任何類型應(yīng)用程序，那么你應(yīng)該使用PKCE extension ，它會提供可能攔截授權(quán)碼的其他攻擊的保護(hù)。
交換授權(quán)碼的步驟確保攻擊者無法攔截access token，這是因為access token總是通過應(yīng)用程序與OAuth服務(wù)器之間的安全反向通道傳輸。
