協(xié)議官網(wǎng)

在傳統(tǒng)的客戶端-服務(wù)器身份驗(yàn)證模型中，客戶端通過使用資源所有者的憑據(jù)向服務(wù)器進(jìn)行身份驗(yàn)證來請(qǐng)求服務(wù)器上的訪問受限資源（受保護(hù)資源）。 為了向第三方應(yīng)用程序提供對(duì)受限資源的訪問，資源所有者與第三方共享其憑證。這產(chǎn)生了若干問題和限制。

第三方應(yīng)用程序需要存儲(chǔ)資源所有者的憑據(jù)以備將來使用，通常是明文密碼。

要求服務(wù)器支持密碼認(rèn)證，盡管密碼存在固有的安全弱點(diǎn)。

第三方應(yīng)用程序獲得對(duì)資源所有者受保護(hù)資源的過于廣泛的訪問權(quán)限，使資源所有者無法限制持續(xù)時(shí)間或訪問有限的資源子集。

資源所有者不能在不撤銷對(duì)所有第三方的訪問權(quán)限的情況下撤銷對(duì)單個(gè)第三方的訪問權(quán)限，必須通過更改第三方的密碼來實(shí)現(xiàn)。

任何第三方應(yīng)用程序的泄露都會(huì)導(dǎo)致最終用戶的密碼和受該密碼保護(hù)的所有數(shù)據(jù)泄露。

OAuth 通過引入授權(quán)層(authorization layer)并將客戶端的角色與資源所有者的角色分開來解決這些問題。在 OAuth 中，客戶端請(qǐng)求訪問由資源所有者控制并由資源服務(wù)器托管的資源，并獲得一組與資源所有者不同的憑據(jù)(credentials)。

客戶端不是使用資源所有者的憑據(jù)來訪問受保護(hù)的資源，而是獲取訪問令牌——一個(gè)表示特定范圍(scope)、生命周期和其他訪問屬性的字符串。訪問令牌由授權(quán)服務(wù)器(authorization server)在資源所有者的批準(zhǔn)下頒發(fā)給第三方客戶端。客戶端使用訪問令牌訪問由資源服務(wù)器托管的受保護(hù)資源。

例如，最終用戶（資源所有者）可以授予打印服務(wù)（客戶端）訪問其存儲(chǔ)在照片共享服務(wù)（資源服務(wù)器）中的受保護(hù)照片的權(quán)限，而無需與打印服務(wù)共享其用戶名和密碼。相反，她直接向照片共享服務(wù)（授權(quán)服務(wù)器）信任的服務(wù)器進(jìn)行身份驗(yàn)證，該服務(wù)器頒發(fā)打印服務(wù)委托特定的憑據(jù)（訪問令牌）。

該規(guī)范設(shè)計(jì)用于 HTTP ([RFC2616])。

OAuth 1.0 協(xié)議 ([RFC5849]) 作為信息文檔發(fā)布，是小型臨時(shí)社區(qū)努力的結(jié)果。此標(biāo)準(zhǔn)跟蹤規(guī)范建立在 OAuth 1.0 部署經(jīng)驗(yàn)以及從更廣泛的 IETF 社區(qū)收集的其他用例和可擴(kuò)展性要求的基礎(chǔ)上。

OAuth 2.0 協(xié)議不向后兼容 OAuth 1.0。這兩個(gè)版本可以在網(wǎng)絡(luò)上共存，并且實(shí)現(xiàn)可以選擇同時(shí)支持這兩個(gè)版本。但是，本規(guī)范的意圖是新實(shí)現(xiàn)支持本文檔中指定的 OAuth 2.0，并且 OAuth 1.0 僅用于支持現(xiàn)有部署。 OAuth 2.0 協(xié)議與 OAuth 1.0 協(xié)議共享很少的實(shí)現(xiàn)細(xì)節(jié)。熟悉 OAuth 1.0 的實(shí)施者應(yīng)該接近本文檔，不要對(duì)其結(jié)構(gòu)和細(xì)節(jié)做任何假設(shè)。

Oauth 里的四個(gè)角色

資源所有者

能夠授予對(duì)受保護(hù)資源的訪問權(quán)限的實(shí)體。

當(dāng)資源所有者是個(gè)人時(shí)，它被稱為最終用戶。

資源服務(wù)器

托管受保護(hù)資源的服務(wù)器，能夠使用訪問令牌接受和響應(yīng)受保護(hù)資源請(qǐng)求。

＃ 客戶 - client

代表資源所有者并經(jīng)其授權(quán)發(fā)出受保護(hù)資源請(qǐng)求的應(yīng)用程序。術(shù)語“客戶端”并不意味著任何特定的實(shí)現(xiàn)特征（例如，應(yīng)用程序是否在服務(wù)器、桌面或其他設(shè)備上執(zhí)行）。

授權(quán)服務(wù)器(authorization server)

服務(wù)器在成功驗(yàn)證資源所有者并獲得授權(quán)后向客戶端頒發(fā)訪問令牌。

授權(quán)服務(wù)器和資源服務(wù)器之間的交互超出了本規(guī)范的范圍。

授權(quán)服務(wù)器可以是與資源服務(wù)器相同的服務(wù)器，也可以是單獨(dú)的實(shí)體。

單個(gè)授權(quán)服務(wù)器可以發(fā)布多個(gè)資源服務(wù)器接受的訪問令牌。

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

(A) 客戶端向資源所有者請(qǐng)求授權(quán)。 授權(quán)請(qǐng)求可以直接發(fā)送給資源所有者，或者最好通過授權(quán)服務(wù)器作為中介間接發(fā)送。

(B) 客戶端收到授權(quán)確認(rèn)，這是代表資源所有者授權(quán)的憑證，使用本規(guī)范中定義的四種授權(quán)類型之一或使用擴(kuò)展授權(quán)類型表示。授權(quán)授權(quán)類型取決于客戶端請(qǐng)求授權(quán)的方法和授權(quán)服務(wù)器支持的類型。

? 客戶端請(qǐng)求訪問令牌，這是通過與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證來完成。

(D) 授權(quán)服務(wù)器對(duì)客戶端進(jìn)行身份驗(yàn)證并驗(yàn)證授權(quán)許可，如果有效，則頒發(fā)訪問令牌。

(E) 客戶端向資源服務(wù)器請(qǐng)求受保護(hù)的資源，并通過提供訪問令牌進(jìn)行身份驗(yàn)證。

(F) 資源服務(wù)器驗(yàn)證訪問令牌，如果有效，則為請(qǐng)求提供服務(wù)。

Authorization Grant

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

Authorization Code

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

在使用授權(quán)碼將資源所有者引導(dǎo)回客戶端之前，授權(quán)服務(wù)器對(duì)資源所有者進(jìn)行身份驗(yàn)證并獲得授權(quán)。由于資源所有者僅通過授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證，因此永遠(yuǎn)不會(huì)與客戶端共享資源所有者的憑據(jù)。

授權(quán)代碼提供了一些重要的安全優(yōu)勢(shì)，例如能夠?qū)蛻舳诉M(jìn)行身份驗(yàn)證，以及將訪問令牌直接傳輸?shù)娇蛻舳?#xff0c;而無需通過資源所有者的用戶代理并可能將其暴露給其他人，包括資源所有者。

Implicit

隱式授權(quán)是針對(duì)使用 JavaScript 等腳本語言在瀏覽器中實(shí)現(xiàn)的客戶端進(jìn)行了優(yōu)化的簡(jiǎn)化授權(quán)代碼流。在隱式流程中，不是向客戶端發(fā)布授權(quán)代碼，而是直接向客戶端發(fā)布訪問令牌（作為資源所有者授權(quán)的結(jié)果）。
授權(quán)類型是隱式的，因?yàn)闆]有頒發(fā)中間憑證（例如授權(quán)代碼）（稍后用于獲取訪問令牌）。

在隱式授權(quán)流程期間發(fā)布訪問令牌時(shí)，授權(quán)服務(wù)器不會(huì)對(duì)客戶端進(jìn)行身份驗(yàn)證。在某些情況下，可以通過用于將訪問令牌傳遞給客戶端的重定向 URI 來驗(yàn)證客戶端身份。訪問令牌可能會(huì)暴露給資源所有者或其他有權(quán)訪問資源所有者的用戶代理的應(yīng)用程序。

隱式授權(quán)提高了某些客戶端（例如作為瀏覽器內(nèi)應(yīng)用程序?qū)崿F(xiàn)的客戶端）的響應(yīng)能力和效率，因?yàn)樗鼫p少了獲取訪問令牌所需的往返次數(shù)。然而，這種便利應(yīng)該與使用隱式授權(quán)的安全隱患進(jìn)行權(quán)衡，尤其是當(dāng)授權(quán)代碼授權(quán)類型可用時(shí)。

Resource Owner Password Credentials

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

盡管此授權(quán)類型需要客戶端直接訪問資源所有者憑據(jù)，但資源所有者憑據(jù)仍用于單個(gè)請(qǐng)求并交換訪問令牌。 通過將憑據(jù)與長(zhǎng)期訪問令牌或刷新令牌交換，此授權(quán)類型可以消除客戶端存儲(chǔ)資源所有者憑據(jù)以備將來使用的需要。

Client Credentials

當(dāng)授權(quán)范圍僅限于客戶端控制下的受保護(hù)資源，或先前與授權(quán)服務(wù)器安排的受保護(hù)資源時(shí)，客戶端憑據(jù)（或其他形式的客戶端身份驗(yàn)證）可用作授權(quán)許可。 客戶端憑據(jù)通常用作授權(quán)授權(quán)，當(dāng)客戶端代表自己行事（客戶端也是資源所有者）或根據(jù)先前與授權(quán)服務(wù)器安排的授權(quán)請(qǐng)求訪問受保護(hù)資源時(shí)。

Access Token

訪問令牌是用于訪問受保護(hù)資源的憑據(jù)。訪問令牌是一個(gè)字符串，表示頒發(fā)給客戶端的授權(quán)。該字符串通常對(duì)客戶端不透明。令牌代表特定的訪問范圍和持續(xù)時(shí)間，由資源所有者授予，并由資源服務(wù)器和授權(quán)強(qiáng)制執(zhí)行
服務(wù)器。

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

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

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

Refresh Token

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

刷新令牌是一個(gè)字符串，表示資源所有者授予客戶端的授權(quán)。 該字符串通常對(duì)客戶端不透明。 令牌表示用于檢索授權(quán)信息的標(biāo)識(shí)符。 與訪問令牌不同，刷新令牌僅用于授權(quán)服務(wù)器，永遠(yuǎn)不會(huì)發(fā)送到資源服務(wù)器。

(A) 客戶端通過與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證并提供授權(quán)許可來請(qǐng)求訪問令牌。

(B) 授權(quán)服務(wù)器對(duì)客戶端進(jìn)行身份驗(yàn)證并驗(yàn)證授權(quán)許可，如果有效，則頒發(fā)訪問令牌和刷新令牌。

? 客戶端通過提供訪問令牌向資源服務(wù)器發(fā)出受保護(hù)的資源請(qǐng)求。

(D) 資源服務(wù)器驗(yàn)證訪問令牌，如果有效，則為請(qǐng)求提供服務(wù)。

(E) 重復(fù)步驟 ? 和 (D)，直到訪問令牌過期。如果客戶端知道訪問令牌已過期，則跳到步驟（G）；否則，它會(huì)發(fā)出另一個(gè)受保護(hù)的資源請(qǐng)求。

(F) 由于訪問令牌無效，資源服務(wù)器返回?zé)o效令牌錯(cuò)誤。

(G) 客戶端通過與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證并提供刷新令牌來請(qǐng)求新的訪問令牌。客戶端身份驗(yàn)證要求基于客戶端類型和授權(quán)服務(wù)器策略。

(H) 授權(quán)服務(wù)器對(duì)客戶端進(jìn)行身份驗(yàn)證并驗(yàn)證刷新令牌，如果有效，則頒發(fā)新的訪問令牌（以及可選的新刷新令牌）。

Refreshing an Access Token

如果授權(quán)服務(wù)器向客戶端發(fā)出刷新令牌，則客戶端通過使用“application/x-www-form-urlencoded”格式添加以下參數(shù)向令牌端點(diǎn)發(fā)出刷新請(qǐng)求，其中字符編碼為UTF-8 HTTP 請(qǐng)求實(shí)體主體：

• 授予類型：必需。值必須設(shè)置為“refresh_token”。

• refresh_token：需要。發(fā)給客戶端的刷新令牌。

由于刷新令牌通常是用于請(qǐng)求其他訪問令牌的持久憑據(jù)，因此刷新令牌綁定到其頒發(fā)給的客戶端。如果客戶端類型是機(jī)密的，或者客戶端獲得了客戶端憑據(jù)（或分配了其他身份驗(yàn)證要求），則客戶端必須向授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證。

例如，客戶端使用傳輸層安全性發(fā)出以下 HTTP 請(qǐng)求（額外的換行符僅用于顯示目的）：

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

授權(quán)服務(wù)器必須：

要求對(duì)機(jī)密客戶端或任何已頒發(fā)客戶端憑據(jù)（或具有其他身份驗(yàn)證要求）的客戶端進(jìn)行客戶端身份驗(yàn)證

如果包含客戶端身份驗(yàn)證，則對(duì)客戶端進(jìn)行身份驗(yàn)證，并確保將刷新令牌頒發(fā)給經(jīng)過身份驗(yàn)證的客戶端，以及

驗(yàn)證刷新令牌。

如果有效并獲得授權(quán)，授權(quán)服務(wù)器會(huì)發(fā)出訪問令牌。 如果請(qǐng)求驗(yàn)證失敗或無效，授權(quán)服務(wù)器返回錯(cuò)誤響應(yīng)。

授權(quán)服務(wù)器可能會(huì)發(fā)出一個(gè)新的刷新令牌，在這種情況下，客戶端必須丟棄舊的刷新令牌并用新的刷新令牌替換它。 授權(quán)服務(wù)器可以在向客戶端發(fā)出新的刷新令牌后撤銷舊的刷新令牌。 如果發(fā)布了新的刷新令牌，則刷新令牌的范圍必須與客戶端在請(qǐng)求中包含的刷新令牌的范圍相同。

Security Considerations

Client Authentication

授權(quán)服務(wù)器與 Web 應(yīng)用程序客戶端建立客戶端憑據(jù)以進(jìn)行客戶端身份驗(yàn)證。鼓勵(lì)授權(quán)服務(wù)器考慮比客戶端密碼更強(qiáng)的客戶端身份驗(yàn)證方法。 Web 應(yīng)用程序客戶端必須確保客戶端密碼和其他客戶端憑據(jù)的機(jī)密性。

授權(quán)服務(wù)器不得出于客戶端身份驗(yàn)證的目的向本機(jī)應(yīng)用程序或基于用戶代理的應(yīng)用程序客戶端發(fā)出客戶端密碼或其他客戶端憑據(jù)。授權(quán)服務(wù)器可以為特定設(shè)備上本地應(yīng)用程序客戶端的特定安裝發(fā)布客戶端密碼或其他憑據(jù)。

當(dāng)客戶端身份驗(yàn)證不可能時(shí)，授權(quán)服務(wù)器應(yīng)該采用其他方式來驗(yàn)證客戶端的身份——例如，通過要求注冊(cè)客戶端重定向 URI 或征集資源所有者來確認(rèn)身份。在請(qǐng)求資源所有者授權(quán)時(shí)，有效的重定向 URI 不足以驗(yàn)證客戶端的身份，但可用于防止在獲得資源所有者授權(quán)后將憑據(jù)傳遞給偽造的客戶端。

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

Client Impersonation

如果被模擬的客戶端未能或無法將其客戶端憑據(jù)保密，則惡意客戶端可以模擬另一個(gè)客戶端并獲得對(duì)受保護(hù)資源的訪問權(quán)限。

授權(quán)服務(wù)器必須盡可能對(duì)客戶端進(jìn)行身份驗(yàn)證。如果由于客戶端的性質(zhì)授權(quán)服務(wù)器無法對(duì)客戶端進(jìn)行身份驗(yàn)證，則授權(quán)服務(wù)器必須要求注冊(cè)任何用于接收授權(quán)響應(yīng)的重定向 URI，并且應(yīng)該使用其他方法來保護(hù)資源所有者免受此類潛在惡意客戶端的侵害。例如，授權(quán)服務(wù)器可以讓資源所有者協(xié)助識(shí)別客戶端及其來源。

授權(quán)服務(wù)器應(yīng)該強(qiáng)制執(zhí)行明確的資源所有者身份驗(yàn)證并向資源所有者提供有關(guān)客戶端和請(qǐng)求的授權(quán)范圍和生命周期的信息。資源所有者可以在當(dāng)前客戶端的上下文中查看信息并授權(quán)或拒絕請(qǐng)求。

授權(quán)服務(wù)器不應(yīng)該在沒有驗(yàn)證客戶端或依賴其他措施的情況下自動(dòng)處理重復(fù)的授權(quán)請(qǐng)求（沒有主動(dòng)的資源所有者交互），以確保重復(fù)的請(qǐng)求來自原始客戶端而不是模仿者。

Access Tokens

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

使用隱式授權(quán)類型時(shí)，訪問令牌在 URI 片段中傳輸，這可能會(huì)將其暴露給未授權(quán)方。

授權(quán)服務(wù)器必須確保未授權(quán)方無法生成、修改或猜測(cè)訪問令牌以生成有效的訪問令牌。

客戶端應(yīng)該請(qǐng)求具有最小必要范圍的訪問令牌。授權(quán)服務(wù)器應(yīng)該在選擇如何接受請(qǐng)求的范圍時(shí)考慮客戶端身份，并且可以發(fā)布權(quán)限少于請(qǐng)求的訪問令牌。

本規(guī)范沒有為資源服務(wù)器提供任何方法來確保授權(quán)服務(wù)器向該客戶端頒發(fā)給定客戶端提供給它的訪問令牌。

Refresh Tokens

授權(quán)服務(wù)器可以向 Web 應(yīng)用程序客戶端和本機(jī)應(yīng)用程序客戶端發(fā)出刷新令牌。

刷新令牌在傳輸和存儲(chǔ)過程中必須保密，并且只能在授權(quán)服務(wù)器和刷新令牌發(fā)給的客戶端之間共享。

授權(quán)服務(wù)器必須維護(hù)刷新令牌和它被頒發(fā)給的客戶端之間的綁定。刷新令牌必須僅使用 TLS 傳輸，并具有 [RFC2818] 定義的服務(wù)器身份驗(yàn)證。

每當(dāng)可以驗(yàn)證客戶端身份時(shí)，授權(quán)服務(wù)器必須驗(yàn)證刷新令牌和客戶端身份之間的綁定。當(dāng)無法進(jìn)行客戶端身份驗(yàn)證時(shí)，授權(quán)服務(wù)器應(yīng)該部署其他方法來檢測(cè)刷新令牌濫用。

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

授權(quán)服務(wù)器必須確保未授權(quán)方無法生成、修改或猜測(cè)刷新令牌以生成有效的刷新令牌。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。