協議官網

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

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

要求服務器支持密碼認證，盡管密碼存在固有的安全弱點。

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

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

任何第三方應用程序的泄露都會導致最終用戶的密碼和受該密碼保護的所有數據泄露。

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) 客戶端收到授權確認，這是代表資源所有者授權的憑證，使用本規范中定義的四種授權類型之一或使用擴展授權類型表示。授權授權類型取決于客戶端請求授權的方法和授權服務器支持的類型。

? 客戶端請求訪問令牌，這是通過與授權服務器進行身份驗證來完成。

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

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

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

Authorization Grant

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

Authorization Code

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

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

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

Implicit

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

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

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

Resource Owner Password Credentials

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

盡管此授權類型需要客戶端直接訪問資源所有者憑據，但資源所有者憑據仍用于單個請求并交換訪問令牌。 通過將憑據與長期訪問令牌或刷新令牌交換，此授權類型可以消除客戶端存儲資源所有者憑據以備將來使用的需要。

Client Credentials

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

Access Token

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

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

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

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

Refresh Token

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

刷新令牌是一個字符串，表示資源所有者授予客戶端的授權。 該字符串通常對客戶端不透明。 令牌表示用于檢索授權信息的標識符。 與訪問令牌不同，刷新令牌僅用于授權服務器，永遠不會發送到資源服務器。

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

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

? 客戶端通過提供訪問令牌向資源服務器發出受保護的資源請求。

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

(E) 重復步驟 ? 和 (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

授權服務器必須：

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

如果包含客戶端身份驗證，則對客戶端進行身份驗證，并確保將刷新令牌頒發給經過身份驗證的客戶端，以及

驗證刷新令牌。

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

授權服務器可能會發出一個新的刷新令牌，在這種情況下，客戶端必須丟棄舊的刷新令牌并用新的刷新令牌替換它。 授權服務器可以在向客戶端發出新的刷新令牌后撤銷舊的刷新令牌。 如果發布了新的刷新令牌，則刷新令牌的范圍必須與客戶端在請求中包含的刷新令牌的范圍相同。

Security Considerations

Client Authentication

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

授權服務器不得出于客戶端身份驗證的目的向本機應用程序或基于用戶代理的應用程序客戶端發出客戶端密碼或其他客戶端憑據。授權服務器可以為特定設備上本地應用程序客戶端的特定安裝發布客戶端密碼或其他憑據。

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

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

Client Impersonation

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

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

授權服務器應該強制執行明確的資源所有者身份驗證并向資源所有者提供有關客戶端和請求的授權范圍和生命周期的信息。資源所有者可以在當前客戶端的上下文中查看信息并授權或拒絕請求。

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

Access Tokens

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

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

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

客戶端應該請求具有最小必要范圍的訪問令牌。授權服務器應該在選擇如何接受請求的范圍時考慮客戶端身份，并且可以發布權限少于請求的訪問令牌。

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

Refresh Tokens

授權服務器可以向 Web 應用程序客戶端和本機應用程序客戶端發出刷新令牌。

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

授權服務器必須維護刷新令牌和它被頒發給的客戶端之間的綁定。刷新令牌必須僅使用 TLS 傳輸，并具有 [RFC2818] 定義的服務器身份驗證。

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

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

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

總結

以上是生活随笔為你收集整理的OAuth 2.0 协议学习笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。