[協議官網](https://datatracker.ietf.org/doc/html/rfc6749#section-1.5)

在傳統的客戶端-伺服器身份驗證模型中，客戶端透過使用資源所有者的憑據向伺服器進行身份驗證來請求伺服器上的訪問受限資源（受保護資源）。 為了向第三方應用程式提供對受限資源的訪問，資源所有者與第三方共享其憑證。這產生了若干問題和限制。

1. 第三方應用程式需要儲存資源所有者的憑據以備將來使用，通常是明文密碼。

2. 要求伺服器支援密碼認證，儘管密碼存在固有的安全弱點。

3. 第三方應用程式獲得對資源所有者受保護資源的過於廣泛的訪問許可權，使資源所有者無法限制持續時間或訪問有限的資源子集。

4. 資源所有者不能在不撤銷對所有第三方的訪問許可權的情況下撤銷對單個第三方的訪問許可權，必須透過更改第三方的密碼來實現。

5. 任何第三方應用程式的洩露都會導致終端使用者的密碼和受該密碼保護的所有資料洩露。

OAuth 透過引入授權層(authorization layer)並將客戶端的角色與資源所有者的角色分開來解決這些問題。在 OAuth 中，客戶端請求訪問由資源所有者控制並由資源伺服器託管的資源，並獲得一組與資源所有者不同的憑據(credentials)。

客戶端不是使用資源所有者的憑據來訪問受保護的資源，而是獲取訪問令牌——一個表示特定範圍(scope)、生命週期和其他訪問屬性的字串。訪問令牌由授權伺服器(authorization server)在資源所有者的批准下頒發給第三方客戶端。客戶端使用訪問令牌訪問由資源伺服器託管的受保護資源。

例如，終端使用者（資源所有者）可以授予列印服務（客戶端）訪問其儲存在照片共享服務（資源伺服器）中的受保護照片的許可權，而無需與列印服務共享其使用者名稱和密碼。相反，她直接向照片共享服務（授權伺服器）信任的伺服器進行身份驗證，該伺服器頒發列印服務委託特定的憑據（訪問令牌）。

該規範設計用於 HTTP ([RFC2616])。

OAuth 1.0 協議 ([RFC5849]) 作為資訊文件釋出，是小型臨時社群努力的結果。此標準跟蹤規範建立在 OAuth 1.0 部署經驗以及從更廣泛的 IETF 社群收集的其他用例和可擴充套件性要求的基礎上。

OAuth 2.0 協議不向後相容 OAuth 1.0。這兩個版本可以在網路上共存，並且實現可以選擇同時支援這兩個版本。但是，本規範的意圖是新實現支援本文件中指定的 OAuth 2.0，並且 OAuth 1.0 僅用於支援現有部署。 OAuth 2.0 協議與 OAuth 1.0 協議共享很少的實現細節。熟悉 OAuth 1.0 的實施者應該接近本文件，不要對其結構和細節做任何假設。

# Oauth 裡的四個角色

## 資源所有者

能夠授予對受保護資源的訪問許可權的實體。

當資源所有者是個人時，它被稱為終端使用者。

## 資源伺服器

託管受保護資源的伺服器，能夠使用訪問令牌接受和響應受保護資源請求。

＃ 客戶 - client

代表資源所有者並經其授權發出受保護資源請求的應用程式。術語“客戶端”並不意味著任何特定的實現特徵（例如，應用程式是否在伺服器、桌面或其他裝置上執行）。

## 授權伺服器(authorization server)

伺服器在成功驗證資源所有者並獲得授權後向客戶端頒發訪問令牌。

授權伺服器和資源伺服器之間的互動超出了本規範的範圍。

授權伺服器可以是與資源伺服器相同的伺服器，也可以是單獨的實體。

單個授權伺服器可以釋出多個資源伺服器接受的訪問令牌。

抽象的 OAuth 2.0 流程描述了四個角色 之間的互動，包括以下步驟：

(A) 客戶端向資源所有者請求授權。 授權請求可以直接傳送給資源所有者，或者最好透過授權伺服器作為中介間接傳送。

(B) 客戶端收到授權確認，這是代表資源所有者授權的憑證，使用本規範中定義的四種授權型別之一或使用擴充套件授權型別表示。授權授權型別取決於客戶端請求授權的方法和授權伺服器支援的型別。

(C) 客戶端請求訪問令牌，這是透過與授權伺服器進行身份驗證來完成。

(D) 授權伺服器對客戶端進行身份驗證並驗證授權許可，如果有效，則頒發訪問令牌。

(E) 客戶端向資源伺服器請求受保護的資源，並透過提供訪問令牌進行身份驗證。

(F) 資源伺服器驗證訪問令牌，如果有效，則為請求提供服務。

# Authorization Grant

授權許可是一種憑證，表示客戶端用於獲取訪問令牌的資源所有者授權（訪問其受保護的資源）。 該規範定義了四種授權型別——授權程式碼、隱式、資源所有者密碼憑據和客戶端憑據——以及用於定義其他型別的可擴充套件性機制。

# Authorization Code

授權碼是透過授權伺服器作為客戶端和資源所有者之間的中介獲得的。客戶端不是直接從資源所有者請求授權，而是將資源所有者引導到授權伺服器（透過其在 [RFC2616] 中定義的使用者代理），後者又將資源所有者引導迴帶有授權程式碼的客戶端。

在使用授權碼將資源所有者引導回客戶端之前，授權伺服器對資源所有者進行身份驗證並獲得授權。由於資源所有者僅透過授權伺服器進行身份驗證，因此永遠不會與客戶端共享資源所有者的憑據。

授權程式碼提供了一些重要的安全優勢，例如能夠對客戶端進行身份驗證，以及將訪問令牌直接傳輸到客戶端，而無需透過資源所有者的使用者代理並可能將其暴露給其他人，包括資源所有者。

# Implicit

隱式授權是針對使用 JavaScript 等指令碼語言在瀏覽器中實現的客戶端進行了最佳化的簡化授權程式碼流。在隱式流程中，不是向客戶端釋出授權程式碼，而是直接向客戶端釋出訪問令牌（作為資源所有者授權的結果）。
授權型別是隱式的，因為沒有頒發中間憑證（例如授權程式碼）（稍後用於獲取訪問令牌）。

在隱式授權流程期間釋出訪問令牌時，授權伺服器不會對客戶端進行身份驗證。在某些情況下，可以透過用於將訪問令牌傳遞給客戶端的重定向 URI 來驗證客戶端身份。訪問令牌可能會暴露給資源所有者或其他有權訪問資源所有者的使用者代理的應用程式。

隱式授權提高了某些客戶端（例如作為瀏覽器內應用程式實現的客戶端）的響應能力和效率，因為它減少了獲取訪問令牌所需的往返次數。然而，這種便利應該與使用隱式授權的安全隱患進行權衡，尤其是當授權程式碼授權型別可用時。

# Resource Owner Password Credentials

資源所有者密碼憑據（即使用者名稱和密碼）可以直接用作授權許可來獲取訪問令牌。 僅當資源所有者和客戶端之間存在高度信任（例如，客戶端是裝置作業系統或高特權應用程式的一部分）並且其他授權授予型別不可用時，才應使用憑據（ 例如授權碼）。

儘管此授權型別需要客戶端直接訪問資源所有者憑據，但資源所有者憑據仍用於單個請求並交換訪問令牌。 透過將憑據與長期訪問令牌或重新整理令牌交換，此授權型別可以消除客戶端儲存資源所有者憑據以備將來使用的需要。

## Client Credentials

當授權範圍僅限於客戶端控制下的受保護資源，或先前與授權伺服器安排的受保護資源時，客戶端憑據（或其他形式的客戶端身份驗證）可用作授權許可。 客戶端憑據通常用作授權授權，當客戶端代表自己行事（客戶端也是資源所有者）或根據先前與授權伺服器安排的授權請求訪問受保護資源時。

# Access Token

訪問令牌是用於訪問受保護資源的憑據。訪問令牌是一個字串，表示頒發給客戶端的授權。該字串通常對客戶端不透明。令牌代表特定的訪問範圍和持續時間，由資源所有者授予，並由資源伺服器和授權強制執行
伺服器。

令牌可以表示用於檢索授權資訊的識別符號，或者可以以可驗證的方式自包含授權資訊（即，由一些資料和簽名組成的令牌字串）。為了讓客戶端使用令牌，可能需要額外的身份驗證憑據，這超出了本規範的範圍。

訪問令牌提供了一個抽象層，用資源伺服器理解的單個令牌替換了不同的授權結構（例如，使用者名稱和密碼）。這種抽象使得頒發訪問令牌比用於獲取它們的授權授予更嚴格，並且消除了資源伺服器瞭解各種身份驗證方法的需要。

根據資源伺服器的安全要求，訪問令牌可以具有不同的格式、結構和使用方法（例如，加密屬性）。訪問令牌屬性和用於訪問受保護資源的方法超出了本規範的範圍，並由諸如 [RFC6750] 的配套規範定義。

# Refresh Token

重新整理令牌是用於獲取訪問令牌的憑據。 重新整理令牌由授權伺服器頒發給客戶端，用於在當前訪問令牌失效或過期時獲取新的訪問令牌，或者獲取具有相同或更窄範圍的附加訪問令牌（訪問令牌可能具有較短的生命週期和 比資源所有者授權的許可權少）。
頒發重新整理令牌是可選的，由授權伺服器決定。 如果授權伺服器釋出重新整理令牌，它會在釋出訪問令牌時包含在內。

重新整理令牌是一個字串，表示資源所有者授予客戶端的授權。 該字串通常對客戶端不透明。 令牌表示用於檢索授權資訊的識別符號。 與訪問令牌不同，重新整理令牌僅用於授權伺服器，永遠不會傳送到資源伺服器。

(A) 客戶端透過與授權伺服器進行身份驗證並提供授權許可來請求訪問令牌。

(B) 授權伺服器對客戶端進行身份驗證並驗證授權許可，如果有效，則頒發訪問令牌和重新整理令牌。

(C) 客戶端透過提供訪問令牌向資源伺服器發出受保護的資源請求。

(D) 資源伺服器驗證訪問令牌，如果有效，則為請求提供服務。

(E) 重複步驟 (C) 和 (D)，直到訪問令牌過期。如果客戶端知道訪問令牌已過期，則跳到步驟（G）；否則，它會發出另一個受保護的資源請求。

(F) 由於訪問令牌無效，資源伺服器返回無效令牌錯誤。

(G) 客戶端透過與授權伺服器進行身份驗證並提供重新整理令牌來請求新的訪問令牌。客戶端身份驗證要求基於客戶端型別和授權伺服器策略。

(H) 授權伺服器對客戶端進行身份驗證並驗證重新整理令牌，如果有效，則頒發新的訪問令牌（以及可選的新重新整理令牌）。

# Refreshing an Access Token

如果授權伺服器向客戶端發出重新整理令牌，則客戶端透過使用“application/x-www-form-urlencoded”格式新增以下引數向令牌端點發出重新整理請求，其中字元編碼為UTF-8 HTTP 請求實體主體：

* 授予型別：必需。值必須設定為“refresh_token”。

* refresh_token：需要。發給客戶端的重新整理令牌。

由於重新整理令牌通常是用於請求其他訪問令牌的持久憑據，因此重新整理令牌繫結到其頒發給的客戶端。如果客戶端型別是機密的，或者客戶端獲得了客戶端憑據（或分配了其他身份驗證要求），則客戶端必須向授權伺服器進行身份驗證。

例如，客戶端使用傳輸層安全性發出以下 HTTP 請求（額外的換行符僅用於顯示目的）：

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

授權伺服器必須：

1. 要求對機密客戶端或任何已頒發客戶端憑據（或具有其他身份驗證要求）的客戶端進行客戶端身份驗證

2. 如果包含客戶端身份驗證，則對客戶端進行身份驗證，並確保將重新整理令牌頒發給經過身份驗證的客戶端，以及

3. 驗證重新整理令牌。

如果有效並獲得授權，授權伺服器會發出訪問令牌。 如果請求驗證失敗或無效，授權伺服器返回錯誤響應。

授權伺服器可能會發出一個新的重新整理令牌，在這種情況下，客戶端必須丟棄舊的重新整理令牌並用新的重新整理令牌替換它。 授權伺服器可以在向客戶端發出新的重新整理令牌後撤銷舊的重新整理令牌。 如果釋出了新的重新整理令牌，則重新整理令牌的範圍必須與客戶端在請求中包含的重新整理令牌的範圍相同。

# Security Considerations

## Client Authentication

授權伺服器與 Web 應用程式客戶端建立客戶端憑據以進行客戶端身份驗證。鼓勵授權伺服器考慮比客戶端密碼更強的客戶端身份驗證方法。 Web 應用程式客戶端必須確保客戶端密碼和其他客戶端憑據的機密性。

授權伺服器不得出於客戶端身份驗證的目的向本機應用程式或基於使用者代理的應用程式客戶端發出客戶端密碼或其他客戶端憑據。授權伺服器可以為特定裝置上本地應用程式客戶端的特定安裝釋出客戶端密碼或其他憑據。

當客戶端身份驗證不可能時，授權伺服器應該採用其他方式來驗證客戶端的身份——例如，透過要求註冊客戶端重定向 URI 或徵集資源所有者來確認身份。在請求資源所有者授權時，有效的重定向 URI 不足以驗證客戶端的身份，但可用於防止在獲得資源所有者授權後將憑據傳遞給偽造的客戶端。

授權伺服器必須考慮與未經身份驗證的客戶端互動的安全隱患，並採取措施限制向此類客戶端頒發的其他憑據（例如重新整理令牌）的潛在暴露。

## Client Impersonation

如果被模擬的客戶端未能或無法將其客戶端憑據保密，則惡意客戶端可以模擬另一個客戶端並獲得對受保護資源的訪問許可權。

授權伺服器必須儘可能對客戶端進行身份驗證。如果由於客戶端的性質授權伺服器無法對客戶端進行身份驗證，則授權伺服器必須要求註冊任何用於接收授權響應的重定向 URI，並且應該使用其他方法來保護資源所有者免受此類潛在惡意客戶端的侵害。例如，授權伺服器可以讓資源所有者協助識別客戶端及其來源。

授權伺服器應該強制執行明確的資源所有者身份驗證並向資源所有者提供有關客戶端和請求的授權範圍和生命週期的資訊。資源所有者可以在當前客戶端的上下文中檢視資訊並授權或拒絕請求。

授權伺服器不應該在沒有驗證客戶端或依賴其他措施的情況下自動處理重複的授權請求（沒有主動的資源所有者互動），以確保重複的請求來自原始客戶端而不是模仿者。

## Access Tokens

訪問令牌憑證（以及任何機密的訪問令牌屬性）必須在傳輸和儲存過程中保密，並且只能在授權伺服器、訪問令牌對其有效的資源伺服器以及訪問令牌頒發給的客戶端之間共享.訪問令牌憑證必須僅使用 TLS 傳輸，並使用 [RFC2818] 定義的伺服器身份驗證。

使用隱式授權型別時，訪問令牌在 URI 片段中傳輸，這可能會將其暴露給未授權方。

授權伺服器必須確保未授權方無法生成、修改或猜測訪問令牌以生成有效的訪問令牌。

客戶端應該請求具有最小必要範圍的訪問令牌。授權伺服器應該在選擇如何接受請求的範圍時考慮客戶端身份，並且可以釋出許可權少於請求的訪問令牌。

本規範沒有為資源伺服器提供任何方法來確保授權伺服器向該客戶端頒發給定客戶端提供給它的訪問令牌。

## Refresh Tokens

授權伺服器可以向 Web 應用程式客戶端和本機應用程式客戶端發出重新整理令牌。

重新整理令牌在傳輸和儲存過程中必須保密，並且只能在授權伺服器和重新整理令牌發給的客戶端之間共享。

授權伺服器必須維護重新整理令牌和它被頒發給的客戶端之間的繫結。重新整理令牌必須僅使用 TLS 傳輸，並具有 [RFC2818] 定義的伺服器身份驗證。

每當可以驗證客戶端身份時，授權伺服器必須驗證重新整理令牌和客戶端身份之間的繫結。當無法進行客戶端身份驗證時，授權伺服器應該部署其他方法來檢測重新整理令牌濫用。

例如，授權伺服器可以使用重新整理令牌輪換，其中每個訪問令牌重新整理響應都會發出一個新的重新整理令牌。先前的重新整理令牌已失效但由授權伺服器保留。如果重新整理令牌被破壞並隨後被攻擊者和合法客戶端使用，其中之一將提供無效的重新整理令牌，這將通知授權伺服器該漏洞。

授權伺服器必須確保未授權方無法生成、修改或猜測重新整理令牌以生成有效的重新整理令牌。

OAuth 2.0 協議學習筆記

相關文章