1. 簡介
在傳統(tǒng)的客戶端-服務(wù)器身份驗(yàn)證模式中，客戶端請(qǐng)求服務(wù)器上限制訪問的資源（受保護(hù)資源）時(shí)，需要使用資源所有者的憑據(jù)在服務(wù)器上進(jìn)行身份驗(yàn)證。
資源所有者為了給第三方應(yīng)用提供受限資源的訪問，需要與第三方共享它的憑據(jù)。 這造成一些問題和局限：
- 需要第三方應(yīng)用存儲(chǔ)資源所有者的憑據(jù)，以供將來使用，通常是明文密碼。
- 需要服務(wù)器支持密碼身份認(rèn)證，盡管密碼認(rèn)證天生就有安全缺陷。
- 第三方應(yīng)用獲得的資源所有者的受保護(hù)資源的訪問權(quán)限過于寬泛，從而導(dǎo)致資源所有者失去對(duì)資源使用時(shí)限或使用范圍的控制。
- 資源所有者不能僅撤銷某個(gè)第三方的訪問權(quán)限而不影響其它，并且，資源所有者只有通過改變第三方的密碼，才能單獨(dú)撤銷這第三方的訪問權(quán)限。
- 與任何第三方應(yīng)用的讓步導(dǎo)致對(duì)終端用戶的密碼及該密碼所保護(hù)的所有數(shù)據(jù)的讓步。
OAuth通過引入授權(quán)層以及分離客戶端角色和資源所有者角色來解決這些問題。
在OAuth中，客戶端在請(qǐng)求受資源所有者控制并托管在資源服務(wù)器上的資源的訪問權(quán)限時(shí)，將被頒發(fā)一組不同于資源所有者所擁有憑據(jù)的憑據(jù)。
客戶端獲得一個(gè)訪問令牌（一個(gè)代表特定作用域、生命期以及其他訪問屬性的字符串），用以代替使用資源所有者的憑據(jù)來訪問受保護(hù)資源。
訪問令牌由授權(quán)服務(wù)器在資源所有者認(rèn)可的情況下頒發(fā)給第三方客戶端。客戶端使用訪問令牌訪問托管在資源服務(wù)器的受保護(hù)資源。
例如，終端用戶（資源所有者）可以許可一個(gè)打印服務(wù)（客戶端）訪問她存儲(chǔ)在圖片分享網(wǎng)站（資源服務(wù)器）上的受保護(hù)圖片，而無需與打印服務(wù)分享自己的用戶名和密碼。
反之，她直接與圖片分享網(wǎng)站信任的服務(wù)器（授權(quán)服務(wù)器）進(jìn)行身份驗(yàn)證，該服務(wù)器頒發(fā)給打印服務(wù)具體委托憑據(jù)（訪問令牌）。
本規(guī)范是為HTTP（RFC2616）協(xié)議量身定制。在任何非HTTP協(xié)議上使用OAuth不在本規(guī)范的范圍之內(nèi)。
OAuth 1.0協(xié)議（RFC5849）作為一個(gè)指導(dǎo)性文檔發(fā)布，是一個(gè)小社區(qū)的工作成果。
本標(biāo)準(zhǔn)化規(guī)范在OAuth 1.0的部署經(jīng)驗(yàn)之上構(gòu)建，也包括其他使用案例以及從更廣泛的IETF社區(qū)收集到的可擴(kuò)展性需求。
OAuth 2.0協(xié)議不向后兼容OAuth 1.0。這兩個(gè)版本可以在網(wǎng)絡(luò)上共存，實(shí)現(xiàn)者可以選擇同時(shí)支持他們。
然而，本規(guī)范的用意是新的實(shí)現(xiàn)支持按本文檔指定的Auth 2.0，OAuth 1.0僅用于支持現(xiàn)有的部署。
OAuth 2.0協(xié)議與OAuth 1.0協(xié)議實(shí)現(xiàn)細(xì)節(jié)沒有太多關(guān)聯(lián)。熟悉OAuth 1.0的實(shí)現(xiàn)者應(yīng)該學(xué)習(xí)本文檔，而不對(duì)有關(guān)OAuth 2.0的結(jié)構(gòu)和細(xì)節(jié)做任何假設(shè)。
Links
1.1. 角色
OAuth定義了四種角色：
-
資源所有者
能夠許可受保護(hù)資源訪問權(quán)限的實(shí)體。當(dāng)資源所有者是個(gè)人時(shí)，它作為最終用戶被提及。
-
資源服務(wù)器
托管受保護(hù)資源的服務(wù)器，能夠接收和響應(yīng)使用訪問令牌對(duì)受保護(hù)資源的請(qǐng)求。
-
客戶端
使用資源所有者的授權(quán)代表資源所有者發(fā)起對(duì)受保護(hù)資源的請(qǐng)求的應(yīng)用程序。術(shù)語“客戶端”并非特指任何特定的的實(shí)現(xiàn)特點(diǎn)（例如：應(yīng)用程序是否在服務(wù)器、臺(tái)式機(jī)或其他設(shè)備上執(zhí)行）。
-
授權(quán)服務(wù)器
在成功驗(yàn)證資源所有者且獲得授權(quán)后頒發(fā)訪問令牌給客戶端的服務(wù)器。
授權(quán)服務(wù)器和資源服務(wù)器之間的交互超出了本規(guī)范的范圍。授權(quán)服務(wù)器可以和資源服務(wù)器是同一臺(tái)服務(wù)器，也可以是分離的個(gè)體。一個(gè)授權(quán)服務(wù)器可以頒發(fā)被多個(gè)資源服務(wù)器接受的訪問令牌。
Links
1.2. 協(xié)議流程
圖1：抽象的協(xié)議流程
圖1中所示的抽象OAuth 2.0流程描述了四個(gè)角色之間的交互，包括以下步驟：
- （A）客戶端向從資源所有者請(qǐng)求授權(quán)。授權(quán)請(qǐng)求可以直接向資源所有者發(fā)起（如圖所示），或者更可取的是通過作為中介的授權(quán)服務(wù)器間接發(fā)起。
- （B）客戶端收到授權(quán)許可，這是一個(gè)代表資源所有者的授權(quán)的憑據(jù)，使用本規(guī)范中定義的四種許可類型之一或 者使用擴(kuò)展許可類型表示。授權(quán)許可類型取決于客戶端請(qǐng)求授權(quán)所使用的方式以及授權(quán)服務(wù)器支持的類型。
- （C）客戶端與授權(quán)服務(wù)器進(jìn)行身份認(rèn)證并出示授權(quán)許可請(qǐng)求訪問令牌。
- （D）授權(quán)服務(wù)器驗(yàn)證客戶端身份并驗(yàn)證授權(quán)許可，若有效則頒發(fā)訪問令牌。
- （E）客戶端從資源服務(wù)器請(qǐng)求受保護(hù)資源并出示訪問令牌進(jìn)行身份驗(yàn)證。
- （F）資源服務(wù)器驗(yàn)證訪問令牌，若有效則滿足該請(qǐng)求。
客戶端用于從資源所有者獲得授權(quán)許可（步驟（A）和（B）所示）的更好方法是使用授權(quán)服務(wù)器作為中介，如4.1節(jié)圖3所示。
Links
1.3. 授權(quán)許可
授權(quán)許可是一個(gè)代表資源所有者授權(quán)（訪問受保護(hù)資源）的憑據(jù)，客戶端用它來獲取訪問令牌。本規(guī)范定義了四種許可類型——授權(quán)碼、隱式許可、資源所有者密碼憑據(jù)和客戶端憑據(jù)——以及用于定義其他類型的可擴(kuò)展性機(jī)制。
Links
1.3.1. 授權(quán)碼
授權(quán)碼通過使用授權(quán)服務(wù)器做為客戶端與資源所有者的中介而獲得?？蛻舳瞬皇侵苯訌馁Y源所有者請(qǐng)求授權(quán)，而是引導(dǎo)資源所有者至授權(quán)服務(wù)器（由在RFC2616中定義的用戶代理），授權(quán)服務(wù)器之后引導(dǎo)資源所有者帶著授權(quán)碼回到客戶端。
在引導(dǎo)資源所有者攜帶授權(quán)碼返回客戶端前，授權(quán)服務(wù)器會(huì)鑒定資源所有者身份并獲得其授權(quán)。由于資源所有者只與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證，所以資源所有者的憑據(jù)不需要與客戶端分享。
授權(quán)碼提供了一些重要的安全益處，例如驗(yàn)證客戶端身份的能力，以及向客戶端直接的訪問令牌的傳輸而非通過資源所有者的用戶代理來傳送它而潛在暴露給他人（包括資源所有者）。
Links
1.3.2. 隱式許可
隱式許可是為用如JavaScript等腳本語言在瀏覽器中實(shí)現(xiàn)的客戶端而優(yōu)化的一種簡化的授權(quán)碼流程。在隱式許可流程中，不再給客戶端頒發(fā)授權(quán)碼，取而代之的是客戶端直接被頒發(fā)一個(gè)訪問令牌（作為資源所有者的授權(quán)）。這種許可類型是隱式的，因?yàn)闆]有中間憑據(jù)（如授權(quán)碼）被頒發(fā)（之后用于獲取訪問令牌）。
當(dāng)在隱式許可流程中頒發(fā)訪問令牌時(shí)，發(fā)授權(quán)服務(wù)器不對(duì)客戶端進(jìn)行身份驗(yàn)證。在某些情況下，客戶端身份可以通過用于向客戶端傳送訪問令牌的重定向URI驗(yàn)證。訪問令牌可能會(huì)暴露給資源所有者，或者對(duì)資源所有者的用戶代理有訪問權(quán)限的其他應(yīng)用程序。
隱式許可提高了一些客戶端（例如一個(gè)作為瀏覽器內(nèi)應(yīng)用實(shí)現(xiàn)的客戶端）的響應(yīng)速度和效率，因?yàn)樗鼫p少了獲取訪問令牌所需的往返數(shù)量。然而，這種便利應(yīng)該和采用隱式許可的安全影響作權(quán)衡，如那些在10.3和10.16節(jié)中所述的，尤其是當(dāng)授權(quán)碼許可類型可用的時(shí)候。
Links
1.3.3. 資源所有者密碼憑據(jù)
資源所有者密碼憑據(jù)（即用戶名和密碼），可以直接作為獲取訪問令牌的授權(quán)許可。這種憑據(jù)只能應(yīng)該當(dāng)資源所有者和客戶端之間具有高度信任時(shí)（例如，客戶端是設(shè)備的操作系統(tǒng)的一部分，或者是一個(gè)高度特權(quán)應(yīng)用程序），以及當(dāng)其他授權(quán)許可類型（例如授權(quán)碼）不可用時(shí)被使用。
盡管本授權(quán)類型需要對(duì)資源所有者憑據(jù)直接的客戶端訪問權(quán)限，但資源所有者憑據(jù)僅被用于一次請(qǐng)求并被交換為訪問令牌。通過憑據(jù)和長期有效的訪問令牌或刷新令牌的互換，這種許可類型可以消除客戶端存儲(chǔ)資源所有者憑據(jù)供將來使用的需要。
Links
1.3.4. 客戶端憑據(jù)
當(dāng)授權(quán)范圍限于客戶端控制下的受保護(hù)資源或事先與授權(quán)服務(wù)器商定的受保護(hù)資源時(shí)客戶端憑據(jù)可以被用作為一種授權(quán)許可。典型的當(dāng)客戶端代表自己表演（客戶端也是資源所有者）或者基于與授權(quán)服務(wù)器事先商定的授權(quán)請(qǐng)求對(duì)受保護(hù)資源的訪問權(quán)限時(shí)，客戶端憑據(jù)被用作為授權(quán)許可。
Links
1.4. 訪問令牌
訪問令牌是用于訪問受保護(hù)資源的憑據(jù)。訪問令牌是一個(gè)代表向客戶端頒發(fā)的授權(quán)的字符串。該字符串通常對(duì)于客戶端是不透明的。令牌代表了訪問權(quán)限的由資源所有者許可并由資源服務(wù)器和授權(quán)服務(wù)器實(shí)施的具體范圍和期限。
令牌可以表示一個(gè)用于檢索授權(quán)信息的標(biāo)識(shí)符或者可以以可驗(yàn)證的方式自包含授權(quán)信息（即令牌字符串由數(shù)據(jù)和簽名組成）。額外的身份驗(yàn)證憑據(jù)——在本規(guī)范范圍以外——可以被要求以便客戶端使用令牌。
訪問令牌提供了一個(gè)抽象層，用單一的資源服務(wù)器能理解的令牌代替不同的授權(quán)結(jié)構(gòu)（例如，用戶名和密碼）。這種抽象使得頒發(fā)訪問令牌比頒發(fā)用于獲取令牌的授權(quán)許可更受限制，同時(shí)消除了資源服務(wù)器理解各種各樣身份認(rèn)證方法的需要。
基于資源服務(wù)器的安全要求訪問令牌可以有不同的格式、結(jié)構(gòu)及采用的方法（如，加密屬性）。訪問令牌的屬性和用于訪問受保護(hù)資源的方法超出了本規(guī)范的范圍，它們?cè)?a title="The OAuth 2.0 Authorization Framework: Bearer Token Usage" href="http://tools./html/rfc6750">RFC6750等配套規(guī)范中定義。
Links
1.5. 刷新令牌
訪問令牌是用于獲取訪問令牌的憑據(jù)。刷新令牌由授權(quán)服務(wù)器頒發(fā)給客戶端，用于在當(dāng)前訪問令牌失效或過期時(shí)，獲取一個(gè)新的訪問令牌，或者獲得相等或更窄范圍的額外的訪問令牌（訪問令牌可能具有比資源所有者所授權(quán)的更短的生命周期和更少的權(quán)限）。頒發(fā)刷新令牌是可選的，由授權(quán)服務(wù)器決定。如果授權(quán)服務(wù)器頒發(fā)刷新令牌，在頒發(fā)訪問令牌時(shí)它被包含在內(nèi)（即圖1中的步驟D）。
刷新令牌是一個(gè)代表由資源所有者給客戶端許可的授權(quán)的字符串。該字符串通常對(duì)于客戶端是不透明的。該令牌表示一個(gè)用于檢索授權(quán)信息的標(biāo)識(shí)符。不同于訪問令牌，刷新令牌設(shè)計(jì)只與授權(quán)服務(wù)器使用，并不會(huì)發(fā)送到資源服務(wù)器。
+--------+ +---------------+| |--(A)------- Authorization Grant --------->| || | | || |<-(B)----------- Access Token -------------| || | & Refresh Token | || | | || | +----------+ | || |--(C)---- Access Token ---->| | | || | | | | || |<-(D)- Protected Resource --| Resource | | Authorization || Client | | Server | | Server || |--(E)---- Access Token ---->| | | || | | | | || |<-(F)- Invalid Token Error -| | | || | +----------+ | || | | || |--(G)----------- Refresh Token ----------->| || | | || |<-(H)----------- Access Token -------------| |+--------+ & Optional Refresh Token +---------------+
圖2：刷新過期的訪問令牌
圖2中的所示流程包含以下步驟：
- （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ā)訪問令牌和刷新令牌。
- （C）客戶端通過出示訪問令牌向資源服務(wù)器發(fā)起受保護(hù)資源的請(qǐng)求。
- （D）資源服務(wù)器驗(yàn)證訪問令牌，若有效則滿足該要求。
- （E）步驟（C）和（D）重復(fù)進(jìn)行，直到訪問令牌到期。如果客戶端知道訪問令牌已過期，跳到步驟（G），否 則它將繼續(xù)發(fā)起另一個(gè)對(duì)受保護(hù)資源的請(qǐng)求。
- （F）由于訪問令牌是無效的，資源服務(wù)器返回?zé)o效令牌錯(cuò)誤。
- （G）客戶端通過與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證并出示刷新令牌，請(qǐng)求一個(gè)新的訪問令牌。客戶端身份驗(yàn)證要求基于客戶端的類型和授權(quán)服務(wù)器的策略。
- （H）授權(quán)服務(wù)器對(duì)客戶端進(jìn)行身份驗(yàn)證并驗(yàn)證刷新令牌，若有效則頒發(fā)一個(gè)新的訪問令牌（和——可選地——一個(gè)新的刷新令牌）。
步驟（C）、（D）、（E）和（F）在本規(guī)范的范圍以外，如第7節(jié)中所述。
Links
1.6. TLS版本
本規(guī)范任何時(shí)候使用傳輸層安全性（TLS），基于廣泛的部署和已知的安全漏洞TLS的相應(yīng)版本（或多個(gè)版本）將會(huì)隨時(shí)間而變化。在本規(guī)范撰寫時(shí)，TLS 1.2版RFC5246是最新的版本，但它具有非常局限的部署基礎(chǔ)，可能還未準(zhǔn)備好可以實(shí)現(xiàn)。TLS 1.0版RFC2246是部署最廣泛的版本并將提供最寬泛的互操作性。
實(shí)現(xiàn)也可以支持滿足其安全需求的其他傳輸層安全機(jī)制。
Links
1.7. HTTP重定向
本規(guī)范廣泛采用了HTTP重定向，有此客戶端或授權(quán)服務(wù)器引導(dǎo)資源所有者的用戶代理到另一個(gè)目的地址。雖然本規(guī)范中的例子演示了HTTP 302狀態(tài)碼的使用，但是任何其他通過用戶代理完成重定向的方法都是允許的并被考慮作為實(shí)現(xiàn)細(xì)節(jié)。
Links
1.8. 互操作性
OAuth 2.0提供了豐富的具有明確的安全性質(zhì)的授權(quán)框架。然而，盡管在其自身看來是一個(gè)帶有許多可選擇組件的豐富且高度可擴(kuò)展的框架，本規(guī)范有可能產(chǎn)生許多非可互操作的實(shí)現(xiàn)。
此外，本規(guī)范中留下一些必需組件部分或完全沒有定義（例如，客戶端注冊(cè)、授權(quán)服務(wù)器性能、端點(diǎn)發(fā)現(xiàn)等）。沒有這些組件，客戶端必須針對(duì)特定的授權(quán)服務(wù)器和資源服務(wù)器被手動(dòng)并專門配置，以進(jìn)行互操作。
本框架設(shè)計(jì)具有一個(gè)明確的期望，即未來工作將定義實(shí)現(xiàn)完整的web范圍的互操作性所需的規(guī)范性的配置和擴(kuò)展。
Links
1.9. 符號(hào)約定
本規(guī)范中的關(guān)鍵詞“必須”、“不能”、“必需的”、“要”、“不要”、“應(yīng)該”、“不應(yīng)該”、“推薦的”、“可以”以及“可選的”按RFC2119所述解釋。
本規(guī)范使用RFC5234的擴(kuò)展巴科斯-諾爾范式(ABNF)表示法。此外，來自“統(tǒng)一資源標(biāo)識(shí)符（URI）：通用語法”RFC3986的規(guī)則URI引用也包含在內(nèi)。
某些安全相關(guān)的術(shù)語按照RFC4949中定義的意思理解。這些術(shù)語包括但不限于：“攻擊”、“身份認(rèn)證”、“授權(quán)”、“證書”、“機(jī)密”，“憑據(jù)”，“加密”，“身份”，“記號(hào)”，“簽名”，“信任”，“驗(yàn)證”和“核實(shí)”。
除非另有說明，所有協(xié)議參數(shù)的名稱和值是大小寫敏感的。
Links
2.0 客戶端注冊(cè)
在開始協(xié)議前，客戶端在授權(quán)服務(wù)器注冊(cè)?？蛻舳嗽谑跈?quán)服務(wù)器上注冊(cè)所通過的方式超出了本規(guī)范，但典型的涉及到最終用戶與HTML注冊(cè)表單的交互。
客戶端注冊(cè)不要求客戶端與授權(quán)服務(wù)器之間的直接交互。在授權(quán)服務(wù)器支持時(shí)，注冊(cè)可以依靠其他方式來建立信任關(guān)系并獲取客戶端的屬性（如重定向URI、客戶端類型）。例如，注冊(cè)可以使用自發(fā)行或第三方發(fā)行聲明或通過授權(quán)服務(wù)器使用信任通道執(zhí)行客戶端發(fā)現(xiàn)完成。
當(dāng)注冊(cè)客戶端時(shí)，客戶端開發(fā)者應(yīng)該：
- 指定2.1節(jié)所述的客戶端類型，
- 提供它的如3.1.2節(jié)所述的客戶端重定向URI，且
- 包含授權(quán)服務(wù)器要求的任何其他信息（如，應(yīng)用名稱、網(wǎng)址、描述、Logo圖片、接受法律條款等）。
- 2.1.客戶端類型
- 2.2.客戶端標(biāo)識(shí)
- 2.3.客戶端身份驗(yàn)證
- 2.3.1.客戶端密碼
- 2.3.2.其他身份驗(yàn)證方法
- 2.4.未注冊(cè)的客戶端
2.1. 客戶端類型
根據(jù)客戶端與授權(quán)服務(wù)器安全地進(jìn)行身份驗(yàn)證的能力（即維護(hù)客戶端憑據(jù)機(jī)密性的能力），OAuth定義了兩種客戶端類型：
- 機(jī)密客戶端
能夠維持其憑據(jù)機(jī)密性（如客戶端執(zhí)行在具有對(duì)客戶端憑據(jù)有限訪問權(quán)限的安全的服務(wù)器上），或者能夠使用 其他方式保證客戶端身份驗(yàn)證的安全性。
- 公開客戶端
不能夠維持其憑據(jù)的機(jī)密性（如客戶端執(zhí)行在由資源所有者使用的設(shè)備上，例如已安裝的本地應(yīng)用程序或基于Web瀏覽器的應(yīng)用），且不能通過其他方式保證客戶端身份驗(yàn)證的安全性。
客戶端類型的選擇基于授權(quán)服務(wù)器的安全身份認(rèn)證定義以及其對(duì)客戶端憑據(jù)可接受的暴露程度。授權(quán)服務(wù)器不應(yīng)該對(duì)客戶端類型做假設(shè)。
客戶端可以以分布式的組件集合實(shí)現(xiàn)，每一個(gè)組件具有不同的客戶端類型和安全上下文（例如，一個(gè)同時(shí)具有機(jī)密的基于服務(wù)器的組件和公開的基于瀏覽器的組件的分布式客戶端）。如果授權(quán)服務(wù)器不提供對(duì)這類客戶端的支持，或不提供其注冊(cè)方面的指導(dǎo)，客戶端應(yīng)該注冊(cè)每個(gè)組件為一個(gè)單獨(dú)的客戶端。
本規(guī)范圍繞下列客戶端配置涉及：
- Web應(yīng)用程序
Web應(yīng)用是一個(gè)運(yùn)行在Web服務(wù)器上的機(jī)密客戶端。資源所有者通過其使用的設(shè)備上的用戶代理里渲染的HTML用戶界面訪問客戶端?？蛻舳藨{據(jù)以及向客戶端頒發(fā)的任何訪問令牌都存儲(chǔ)在Web服務(wù)器上且不會(huì)暴露給資源所有者或者被資源所有者可訪問。
- 基于用戶代理的應(yīng)用
基于用戶代理的應(yīng)用是一個(gè)公開客戶端，客戶端的代碼從Web服務(wù)器下載，并在資源所有者使用的設(shè)備上的用戶代理（如Web瀏覽器）中執(zhí)行。協(xié)議數(shù)據(jù)和憑據(jù)對(duì)于資源所有者是可輕易訪問的（且經(jīng)常是可見的）。由于這些應(yīng)用駐留在用戶代理內(nèi)，在請(qǐng)求授權(quán)時(shí)它們可以無縫地使用用戶代理的功能。
- 本機(jī)應(yīng)用程序
本機(jī)應(yīng)用是一個(gè)安裝、運(yùn)行在資源所有者使用的設(shè)備上的公開客戶端。協(xié)議數(shù)據(jù)和憑據(jù)對(duì)于資源所有者是可訪問的。假定包含在應(yīng)用程序中的任何客戶端身份認(rèn)證憑據(jù)可以被提取。另一方面，動(dòng)態(tài)頒發(fā)的如訪問令牌或者刷新令牌等憑據(jù)可以達(dá)到可接受的保護(hù)水平。至少，這些憑據(jù)被保護(hù)不被應(yīng)用可能與之交互的惡意服務(wù)器接觸。在一些平臺(tái)上，這些憑證可能被保護(hù)免于被駐留在相同設(shè)備上的其他應(yīng)用接觸。
2.2. 客戶端標(biāo)識(shí)
授權(quán)服務(wù)器頒發(fā)給已注冊(cè)客戶端客戶端標(biāo)識(shí)——一個(gè)代表客戶端提供的注冊(cè)信息的唯一字符串?？蛻舳藰?biāo)識(shí)不是一個(gè)秘密，它暴露給資源所有者并且不能單獨(dú)用于客戶端身份驗(yàn)證。客戶端標(biāo)識(shí)對(duì)于授權(quán)服務(wù)器是唯一的。
客戶端的字符串大小本規(guī)范未定義?？蛻舳藨?yīng)該避免對(duì)標(biāo)識(shí)大小做假設(shè)。授權(quán)服務(wù)器應(yīng)記錄其發(fā)放的任何標(biāo)識(shí)的大小。
2.3. 客戶端身份驗(yàn)證
如果客戶端類型是機(jī)密的，客戶端和授權(quán)服務(wù)器建立適合于授權(quán)服務(wù)器的安全性要求的客戶端身份驗(yàn)證方法。授權(quán)服務(wù)器可以接受符合其安全要求的任何形式的客戶端身份驗(yàn)證。
機(jī)密客戶端通常頒發(fā)（或建立）一組客戶端憑據(jù)用于與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證（例如，密碼、公/私鑰對(duì)）。授權(quán)服務(wù)器可以與公共客戶端建立客戶端身份驗(yàn)證方法。然而，授權(quán)服務(wù)器不能依靠公共客戶端身份驗(yàn)證達(dá)到識(shí)別客戶端的目的。
客戶端在每次請(qǐng)求中不能使用一個(gè)以上的身份驗(yàn)證方法。
- 2.3.1.客戶端密碼
-
2.3.2.其他身份驗(yàn)證方法
2.3.1. 客戶端密碼
擁有客戶端密碼的客戶端可以使用RFC2617中定義的HTTP基本身份驗(yàn)證方案與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證?？蛻舳藰?biāo)識(shí)使用按照附錄B的“application/x-www-form-urlencoded”編碼算法編碼，編碼后的值用作用戶名；客戶端密碼使用相同的算法編碼并用作密碼。授權(quán)服務(wù)器必須支持HTTP基本身份驗(yàn)證方案，用于驗(yàn)證被頒發(fā)客戶端密碼的客戶端的身份。例如（額外的換行僅用于顯示目的）：
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
此外，授權(quán)服務(wù)器可以使用下列參數(shù)支持在請(qǐng)求正文中包含客戶端憑據(jù)：
- client_id
必需的。如2.2節(jié)所述的注冊(cè)過程中頒發(fā)給客戶端的客戶端標(biāo)識(shí)。
- client_secret
必需的?？蛻舳嗣孛堋?客戶端可以忽略該參數(shù)若客戶端秘密是一個(gè)空字符串。
使用這兩個(gè)參數(shù)在請(qǐng)求正文中包含客戶端憑據(jù)是不被建議的，應(yīng)該限于不能直接采用HTTP基本身份驗(yàn)證方案（或其他基于密碼的HTTP身份驗(yàn)證方案）的客戶端。參數(shù)只能在請(qǐng)求正文中傳送，不能包含在請(qǐng)求URI中。
例如，使用請(qǐng)求正文參數(shù)請(qǐng)求刷新訪問令牌（第6節(jié)）（額外的換行僅用于顯示目的）：
POST /token HTTP/1.1 Host: server. Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
當(dāng)使用密碼身份驗(yàn)證發(fā)送請(qǐng)求時(shí)，授權(quán)服務(wù)器必須要求使用如1.6所述的TLS。
由于該客戶端身份驗(yàn)證方法包含密碼，授權(quán)服務(wù)器必須保護(hù)所有使用到密碼的端點(diǎn)免受暴力攻擊。
2.3.2. 其他身份驗(yàn)證方法
授權(quán)服務(wù)器可以支持任何與其安全要求匹配的合適的HTTP身份驗(yàn)證方案。當(dāng)使用其他身份驗(yàn)證方法時(shí)，授權(quán)服務(wù)器必須定義客戶端標(biāo)識(shí)（注冊(cè)記錄）和認(rèn)證方案之間的映射。
2.4. 未注冊(cè)客戶端
本規(guī)范不排除使用未注冊(cè)的客戶端。然而，使用這樣的客戶端超出了本規(guī)范的范圍，并需要額外的安全性分析并審查其互操作性影響。
3. 協(xié)議端點(diǎn)
授權(quán)過程采用了兩種授權(quán)服務(wù)器端點(diǎn)（HTTP資源）：
- 授權(quán)端點(diǎn)——客戶端用其通過用戶代理重定向從資源所有者獲取授權(quán)。
- 令牌端點(diǎn)——客戶端用其將授權(quán)許可交換為訪問令牌，通常伴有客戶端身份驗(yàn)證。
以及一種客戶端端點(diǎn)：
- 重定向端點(diǎn)——授權(quán)服務(wù)器用其通過資源所有者用戶代理向客戶端返回含有授權(quán)憑據(jù)的響應(yīng)。
并不是每種授權(quán)許可類型都采用兩種端點(diǎn)。
擴(kuò)展許可類型可以按需定義其他端點(diǎn)。
客戶端通過何種方式獲得授權(quán)端點(diǎn)的位置超出了本文檔范圍，但該位置通常在服務(wù)文檔中提供。
端點(diǎn)URI可以包含“application/x-www-form-urlencoded”格式（按附錄B）的查詢部分（RFC3986的3.4節(jié)），當(dāng)添加額外的查詢參數(shù)時(shí)必須保留該部分。端點(diǎn)URI不得包含片段部分。
由于向授權(quán)端點(diǎn)的請(qǐng)求引起用戶身份驗(yàn)證和明文憑據(jù)傳輸（在HTTP響應(yīng)中），當(dāng)向授權(quán)端點(diǎn)發(fā)送請(qǐng)求時(shí)，授權(quán)服務(wù)器必須要求如1.6節(jié)所述的TLS的使用。
授權(quán)服務(wù)器對(duì)于授權(quán)端點(diǎn)必須支持使用HTTP“GET”方法RFC2616，也可以支持使用“POST”的方法。
發(fā)送的沒有值的參數(shù)必須被對(duì)待為好像它們?cè)谡?qǐng)求中省略了。授權(quán)服務(wù)器必須忽略不能識(shí)別的請(qǐng)求參數(shù)。 請(qǐng)求和響應(yīng)參數(shù)不能包含超過一次。
3.1.1. 響應(yīng)類型
授權(quán)端點(diǎn)被授權(quán)碼許可類型和隱式許可類型流程使用?？蛻舳耸褂孟铝袇?shù)通知授權(quán)服務(wù)器期望的許可類型：
- response_type
必需的。其值必須是如4.1.1節(jié)所述用于請(qǐng)求授權(quán)碼的“code”，如4.2.1節(jié)所述用于請(qǐng)求訪問令牌的“token”（隱式許可）或者如8.4節(jié)所述的一個(gè)注冊(cè)的擴(kuò)展值之中的一個(gè)。
擴(kuò)展響應(yīng)類型可以包含一個(gè)空格（%x20）分隔的值的列表，值的順序并不重要（例如，響應(yīng)類型“a b”與“b a”相同）。 這樣的復(fù)合響應(yīng)類型的含義由他們各自的規(guī)范定義。
如果授權(quán)請(qǐng)求缺少“response_type”參數(shù)，或者如果響應(yīng)類型不被理解，授權(quán)服務(wù)器必須返回一個(gè)4.1.2.1所述的錯(cuò)誤響應(yīng)。
3.1.2. 重定向端點(diǎn)
在完成與資源所有者的交互后，授權(quán)服務(wù)器引導(dǎo)資源所有者的用戶代理返回到客戶端。授權(quán)服務(wù)器重定向用戶代理至客戶端的重定向端點(diǎn)，該端點(diǎn)是事先在客戶端注冊(cè)過程中或者當(dāng)發(fā)起授權(quán)請(qǐng)求時(shí)與授權(quán)服務(wù)器建立的。
重定向端點(diǎn)URI必須是如RFC3986的3.4節(jié)所述的絕對(duì)URI。端點(diǎn)URI可以包含“application/x-www-form-urlencoded”格式（按附錄B）的查詢部分（RFC3986的3.4節(jié)），當(dāng)添加額外的查詢參數(shù)時(shí)必須保留該部分。端點(diǎn)URI不得包含片段部分。
3.1.2.1. 端點(diǎn)請(qǐng)求的機(jī)密性
當(dāng)所請(qǐng)求的響應(yīng)類型是“code”或“token”時(shí)，或者當(dāng)重定向請(qǐng)求將引起在蜜柑憑據(jù)通過公開網(wǎng)絡(luò)傳輸時(shí)，重定向端點(diǎn)應(yīng)該要求使用1.6節(jié)所述的TLS。本規(guī)范沒有強(qiáng)制使用TLS，因?yàn)樵谧珜懕疽?guī)范時(shí)，要求客戶端部署TLS對(duì)于許多客戶端開發(fā)者是一嚴(yán)重的困難。如果TLS不可用，授權(quán)服務(wù)器應(yīng)該在重定向之前警告資源所有者有關(guān)非安全端點(diǎn)（例如，在授權(quán)請(qǐng)求期間現(xiàn)實(shí)一條信息）。
缺乏傳輸層安全可能對(duì)客戶端及它被授權(quán)訪問的受保護(hù)資源的安全具有嚴(yán)重影響。當(dāng)授權(quán)過程用作一種客戶端委托的對(duì)最終用戶認(rèn)證（例如，第三方登錄服務(wù)）的形式時(shí)，使用傳輸層安全尤其關(guān)鍵。
3.1.2.2. 注冊(cè)要求
授權(quán)服務(wù)器必須要求下列客戶端注冊(cè)它們的重定向端點(diǎn)：
- 公開客戶端。
- 采用隱式許可類型的機(jī)密客戶端。
授權(quán)服務(wù)器應(yīng)該要求所有客戶端在使用授權(quán)端點(diǎn)前注冊(cè)它們的重定向端點(diǎn)。
授權(quán)服務(wù)器應(yīng)該要求客戶端提供完整的重定向URI（客戶端可以使用“state”請(qǐng)求參數(shù)實(shí)現(xiàn)每請(qǐng)求自定義）。如果要求完整的重定向URI注冊(cè)不可行，授權(quán)服務(wù)器應(yīng)該要求注冊(cè)URI方案、授權(quán)和路徑（當(dāng)請(qǐng)求授權(quán)時(shí)只允許客戶端動(dòng)態(tài)改變重定向URI的查詢部分）。
授權(quán)服務(wù)器可以允許客戶端注冊(cè)多個(gè)重定向端點(diǎn)。
缺少重定向URI注冊(cè)的要求，可能使攻擊者如10.15所述將授權(quán)端點(diǎn)用作自由重定向端點(diǎn)。
3.1.2.3. 動(dòng)態(tài)配置
如果多個(gè)重定向URI被注冊(cè)，或者如果只有部分重定向URI被注冊(cè)，或者如果沒有重定向URI被注冊(cè)，客戶端都必須使用“redirect_uri”請(qǐng)求參數(shù)在授權(quán)請(qǐng)求中包含重定向URI。
當(dāng)重定向URI被包含在授權(quán)請(qǐng)求中時(shí)，若有任何重定向URI被注冊(cè)，授權(quán)服務(wù)器必須將接收到的值與至少一個(gè)已注冊(cè)的重定向URI（或URI部分）按RFC3986第6節(jié)所述進(jìn)行比較并匹配。如果客戶端注冊(cè)包含了完整的重定向URI，授權(quán)服務(wù)器必須使用RFC3986第6.2.1節(jié)中定義的簡單字符串比較法比對(duì)這兩個(gè)URI 。
3.1.2.4. 無效端點(diǎn)
如果由于缺失、無效或不匹配的重定向URI而驗(yàn)證失敗，授權(quán)服務(wù)器應(yīng)該通知資源所有者該錯(cuò)誤且不能向無效的重定向URI自動(dòng)重定向用戶代理。
3.1.2.5. 端點(diǎn)內(nèi)容
向客戶端端點(diǎn)的重定向請(qǐng)求通常會(huì)引起由用戶代理處理的HTML文檔響應(yīng)。如果HTML響應(yīng)直接作為重定向請(qǐng)求的服務(wù)結(jié)果，任何包含在HTML文檔中的腳本將執(zhí)行，并具有對(duì)重定向URI和其包含的憑據(jù)的完全訪問權(quán)限。
客戶端不應(yīng)該在重定向端點(diǎn)的響應(yīng)中包含任何第三方的腳本（例如，第三方分析、社交插件、廣告網(wǎng)絡(luò)）。相反，它應(yīng)該從URI中提取憑據(jù)并向另一個(gè)端點(diǎn)重定向用戶代理而不暴露憑據(jù)（在URI中或其他地方）。如果包含第三方腳本，客戶端必須確保它自己的腳本（用于從URI中提取憑據(jù)并從URI中刪除）將首先執(zhí)行。
3.2. 令牌端點(diǎn)
客戶端通過提交它的授權(quán)許可或刷新令牌使用令牌端點(diǎn)獲取訪問令牌。令牌端點(diǎn)被用于除了隱式許可類型（因?yàn)樵L問令牌是直接頒發(fā)的）外的每種授權(quán)許可中。
客戶端通過何種方式獲得令牌端點(diǎn)的位置超出了本文檔范圍，但該位置通常在服務(wù)文檔中提供。
端點(diǎn)URI可以包含“application/x-www-form-urlencoded”格式（按附錄B）的查詢部分（RFC3986的3.4節(jié)），當(dāng)添加額外的查詢參數(shù)時(shí)必須保留該部分。端點(diǎn)URI不得包含片段部分。
由于向令牌端點(diǎn)的請(qǐng)求引起明文憑據(jù)的傳輸（在HTTP請(qǐng)求和響應(yīng)中），當(dāng)向令牌端點(diǎn)發(fā)送請(qǐng)求時(shí)，授權(quán)服務(wù)器必須要求如1.6節(jié)所述的TLS的使用。
當(dāng)發(fā)起訪問令牌請(qǐng)求時(shí)，客戶端必須使用HTTP“POST”方法。
發(fā)送的沒有值的參數(shù)必須被對(duì)待為好像它們?cè)谡?qǐng)求中省略了。授權(quán)服務(wù)器必須忽略不能識(shí)別的請(qǐng)求參數(shù)。請(qǐng)求和響應(yīng)參數(shù)不能包含超過一次。
3.2.1. 客戶端身份驗(yàn)證
在向令牌端點(diǎn)發(fā)起請(qǐng)求時(shí)，機(jī)密客戶端或其他被頒發(fā)客戶端憑據(jù)的客戶端必須如2.3節(jié)所述與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證?？蛻舳松矸蒡?yàn)證用于：
- 實(shí)施刷新令牌和授權(quán)碼到它們被頒發(fā)給的客戶端的綁定。當(dāng)授權(quán)碼在不安全通道上向重定向端點(diǎn)傳輸時(shí)，或者 當(dāng)重定向URI沒有被完全注冊(cè)時(shí)，客戶端身份驗(yàn)證是關(guān)鍵的。
- 通過禁用客戶端或者改變其憑據(jù)從被入侵的客戶端恢復(fù)，從而防止攻擊者濫用被盜的刷新令牌。改變單套客戶端憑據(jù)顯然快于撤銷一整套刷新令牌。
- 實(shí)現(xiàn)身份驗(yàn)證管理的最佳實(shí)踐，要求定期憑證輪轉(zhuǎn)。輪轉(zhuǎn)一整套刷新令牌可能是艱巨的，而輪轉(zhuǎn)單組客戶端憑據(jù)顯然更容易。
在向令牌端點(diǎn)發(fā)送請(qǐng)求時(shí)，客戶端可以使用“client_id”請(qǐng)求參數(shù)標(biāo)識(shí)自己。向令牌端點(diǎn)的“authorization_code”和“grant_type”請(qǐng)求中，未經(jīng)身份驗(yàn)證的客戶端必須發(fā)送它的“client_id”，以防止自己無意中接受了本打算給具有另一個(gè)“client_id”的客戶端的代碼。這保護(hù)了客戶端免于被替換認(rèn)證碼。（它沒有對(duì)手保護(hù)起源提供額外的安全。）
3.3. 訪問令牌范圍
授權(quán)端點(diǎn)和令牌端點(diǎn)允許客戶端使用“scope”請(qǐng)求參數(shù)指定訪問請(qǐng)求的范圍。反過來，授權(quán)服務(wù)器使用“scope”響應(yīng)參數(shù)通知客戶端頒發(fā)的訪問令牌的范圍。
范圍參數(shù)的值表示為以空格分隔，大小寫敏感的字符串。 由授權(quán)服務(wù)器定義該字符串。如果該值包含多個(gè)空格分隔的字符串，他們的順序并不重要且每個(gè)字符串為請(qǐng)求的范圍添加一個(gè)額外的訪問區(qū)域。
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
基于授權(quán)服務(wù)器的策略或資源擁有者的指示，授權(quán)服務(wù)器可以全部或部分地忽略客戶端請(qǐng)求的范圍。如果頒發(fā)的訪問令牌范圍和客戶端請(qǐng)求的范圍不同，授權(quán)服務(wù)器必須包含“scope”響應(yīng)參數(shù)通知客戶端實(shí)際許可的范圍。
在請(qǐng)求授權(quán)時(shí)如果客戶端忽略了范圍參數(shù)，授權(quán)服務(wù)器必須要么使用預(yù)定義的默認(rèn)值處理請(qǐng)求，要么使請(qǐng)求失敗以指出無效范圍。授權(quán)服務(wù)器應(yīng)該記錄它的范圍需求和默認(rèn)值（如果已定義）。
4. 獲得授權(quán)
為了請(qǐng)求訪問令牌，客戶端從資源所有者獲得授權(quán)。授權(quán)表現(xiàn)為授權(quán)許可的形式，客戶端用它請(qǐng)求訪問令牌。OAuth定義了四種許可類型：授權(quán)碼、隱式許可、資源所有者密碼憑據(jù)和客戶端憑據(jù)。它還提供了擴(kuò)展機(jī)制定義其他許可類型。
在圖3中所示的流程包括以下步驟：
客戶端使用HTTP重定向響應(yīng)向構(gòu)造的URI定向資源所有者，或者通過經(jīng)由用戶代理至該URI的其他可用方法。
例如，客戶端使用TLS定向用戶代理發(fā)起下述HTTP請(qǐng)求（額外的換行僅用于顯示目的）：
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1Host: server.
授權(quán)服務(wù)器驗(yàn)證該請(qǐng)求，確保所有需要的參數(shù)已提交且有效。如果請(qǐng)求是有效的，授權(quán)服務(wù)器對(duì)資源所有者進(jìn)行身份驗(yàn)證并獲得授權(quán)決定（通過詢問資源所有者或通過經(jīng)由其他方式確定批準(zhǔn)）。
當(dāng)確定決定后，授權(quán)服務(wù)器使用HTTP重定向響應(yīng)向提供的客戶端重定向URI定向用戶代理，或者通過經(jīng)由用戶代理至該URI的其他可行方法。
4.1.2. 授權(quán)響應(yīng)
如果資源所有者許可訪問請(qǐng)求，授權(quán)服務(wù)器頒發(fā)授權(quán)碼，通過按附錄B使用“application/x-www-form-urlencoded”格式向重定向URI的查詢部分添加下列參數(shù)傳遞授權(quán)碼至客戶端：
- code
必需的。授權(quán)服務(wù)器生成的授權(quán)碼。授權(quán)碼必須在頒發(fā)后很快過期以減小泄露風(fēng)險(xiǎn)。推薦的最長的授權(quán)碼生命周期是10分鐘?？蛻舳瞬荒苁褂檬跈?quán)碼超過一次。如果一個(gè)授權(quán)碼被使用一次以上，授權(quán)服務(wù)器必須拒絕該請(qǐng)求并應(yīng)該撤銷（如可能）先前發(fā)出的基于該授權(quán)碼的所有令牌。授權(quán)碼與客戶端標(biāo)識(shí)和重定向URI綁定。
- state
必需的，若“state”參數(shù)在客戶端授權(quán)請(qǐng)求中提交。從客戶端接收的精確值。
例如，授權(quán)服務(wù)器通過發(fā)送以下HTTP響應(yīng)重定向用戶代理：
HTTP/1.1 302 FoundLocation: https://client./cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
客戶端必須忽略無法識(shí)別的響應(yīng)參數(shù)。本規(guī)范未定義授權(quán)碼字符串大小?？蛻舳藨?yīng)該避免假設(shè)代碼值的長度。授權(quán)服務(wù)器應(yīng)記錄其發(fā)放的任何值的大小。
- 4.1.2.1.錯(cuò)誤響應(yīng)
4.1.2.1. 錯(cuò)誤響應(yīng)
如果由于缺失、無效或不匹配的重定向URI而請(qǐng)求失敗，或者如果客戶端表示缺失或無效，授權(quán)服務(wù)器應(yīng)該通知資源所有者該錯(cuò)誤且不能向無效的重定向URI自動(dòng)重定向用戶代理。
如果資源所有者拒絕訪問請(qǐng)求，或者如果請(qǐng)求因?yàn)槠渌侨笔Щ驘o效重定向URI原因而失敗，授權(quán)服務(wù)器通過按附錄B使用“application/x-www-form-urlencoded”格式向重定向URI的查詢部分添加下列參數(shù)通知客戶端：
例如，授權(quán)服務(wù)器通過發(fā)送以下HTTP響應(yīng)重定向用戶代理：
HTTP/1.1 302 FoundLocation: https://client./cb?error=access_denied&state=xyz
4.1.3. 訪問令牌請(qǐng)求
客戶端通過使用按附錄B“application/x-www-form-urlencoded”格式在HTTP請(qǐng)求實(shí)體正文中發(fā)送下列UTF-8字符編碼的參數(shù)向令牌端點(diǎn)發(fā)起請(qǐng)求：
- grant_type
必需的。值必須被設(shè)置為“authorization_code”。
- code
從授權(quán)服務(wù)器收到的授權(quán)碼。
- redirect_uri
必需的，若“redirect_uri”參數(shù)如4.1.1節(jié)所述包含在授權(quán)請(qǐng)求中，且他們的值必須相同。
- client_id
必需的，如果客戶端沒有如3.2.1節(jié)所述與授權(quán)服務(wù)器進(jìn)行身份認(rèn)證。
如果客戶端類型是機(jī)密的或客戶端被頒發(fā)了客戶端憑據(jù)（或選定的其他身份驗(yàn)證要求），客戶端必須如
必需的，如果客戶端沒有如3.2.1節(jié)所述與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證。
例如，客戶端使用TLS發(fā)起如下的HTTP請(qǐng)求（額外的換行符僅用于顯示目的）：
POST /token HTTP/1.1Host: server.Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type: application/x-www-form-urlencodedgrant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
授權(quán)服務(wù)器必須：
- 要求機(jī)密客戶端或任何被頒發(fā)了客戶端憑據(jù)（或有其他身份驗(yàn)證要求）的客戶端進(jìn)行客戶端身份驗(yàn)證，
- 若包括了客戶端身份驗(yàn)證，驗(yàn)證客戶端身份，
- 確保授權(quán)碼頒發(fā)給了通過身份驗(yàn)證的機(jī)密客戶端，或者如果客戶端是公開的，確保代碼頒發(fā)給了請(qǐng)求中的“client_id”，
- 驗(yàn)證授權(quán)碼是有效的，并
- 確保給出了“redirect_uri”參數(shù)，若“redirect_uri”參數(shù)如4.1.1所述包含在初始授權(quán)請(qǐng)求中，且若包含，確保它們的值是相同的。
4.1.4. 訪問令牌響應(yīng)
如果訪問令牌請(qǐng)求是有效的且被授權(quán)，授權(quán)服務(wù)器如5.1節(jié)所述頒發(fā)訪問令牌以及可選的刷新令牌。如果請(qǐng)求客戶端身份驗(yàn)證失敗或無效，授權(quán)服務(wù)器如5.2節(jié)所述的返回錯(cuò)誤響應(yīng)。
一個(gè)樣例成功響應(yīng)：
HTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: no-cache{ 'access_token':'2YotnFZFEjr1zCsicMWpAA', 'token_type':'example', 'expires_in':3600, 'refresh_token':'tGzv3JOkF0XG5Qx2TlKWIA', 'example_parameter':'example_value'}
4.2. 隱式許可
隱式授權(quán)類型被用于獲取訪問令牌（它不支持發(fā)行刷新令牌），并對(duì)知道操作具體重定向URI的公共客戶端進(jìn)行優(yōu)化。這些客戶端通常在瀏覽器中使用諸如JavaScript的腳本語言實(shí)現(xiàn)。
由于這是一個(gè)基于重定向的流程，客戶端必須能夠與資源所有者的用戶代理（通常是Web瀏覽器）進(jìn)行交互并能夠接收來自授權(quán)服務(wù)器的傳入請(qǐng)求（通過重定向）。
不同于客戶端分別請(qǐng)求授權(quán)和訪問令牌的授權(quán)碼許可類型，客戶端收到訪問令牌作為授權(quán)請(qǐng)求的結(jié)果。
隱式許可類型不包含客戶端身份驗(yàn)證而依賴于資源所有者在場和重定向URI的注冊(cè)。因?yàn)樵L問令牌被編碼到重定向URI中，它可能會(huì)暴露給資源所有者和其他駐留在相同設(shè)備上的應(yīng)用。
+----------+ | Resource | | Owner | | | +----------+ ^ | (B) +----|-----+ Client Identifier +---------------+ | -+----(A)-- & Redirection URI --->| | | User- | | Authorization | | Agent -|----(B)-- User authenticates -->| Server | | | | | | |<---(C)--- Redirection URI ----<| | | | with Access Token +---------------+ | | in Fragment | | +---------------+ | |----(D)--- Redirection URI ---->| Web-Hosted | | | without Fragment | Client | | | | Resource | | (F) |<---(E)------- Script ---------<| | | | +---------------+ +-|--------+ | | (A) (G) Access Token | | ^ v +---------+ | | | Client | | | +---------+
注：說明步驟（A）和（B）的直線因?yàn)橥ㄟ^用戶代理而被分為兩部分。
圖4：隱式許可流程
圖4中的所示流程包含以下步驟：
- （A）客戶端通過向授權(quán)端點(diǎn)引導(dǎo)資源所有者的用戶代理開始流程?？蛻舳税ㄋ目蛻舳藰?biāo)識(shí)、請(qǐng)求范圍、本地狀態(tài)和重定向URI，一旦訪問被許可（或拒絕）授權(quán)服務(wù)器將傳送用戶代理回到該URI。
- （B）授權(quán)服務(wù)器驗(yàn)證資源擁有者的身份（通過用戶代理），并確定資源所有者是否授予或拒絕客戶端的訪問請(qǐng)求。
- （C）假設(shè)資源所有者許可訪問，授權(quán)服務(wù)器使用之前（在請(qǐng)求時(shí)或客戶端注冊(cè)時(shí)）提供的重定向URI重定向用戶代理回到客戶端。重定向URI在URI片段中包含訪問令牌。
- （D）用戶代理順著重定向指示向Web托管的客戶端資源發(fā)起請(qǐng)求（按RFC2616該請(qǐng)求不包含片段）。用戶代理在本地保留片段信息。
- （E）Web托管的客戶端資源返回一個(gè)網(wǎng)頁（通常是帶有嵌入式腳本的HTML文檔），該網(wǎng)頁能夠訪問包含用戶代理保留的片段的完整重定向URI并提取包含在片段中的訪問令牌（和其他參數(shù)）。
- （F）用戶代理在本地執(zhí)行Web托管的客戶端資源提供的提取訪問令牌的腳本。
- （G）用戶代理傳送訪問令牌給客戶端。
參見1.3.2節(jié)和第9節(jié)了解使用隱式許可的背景。
參見10.3節(jié)和10.16節(jié)了解當(dāng)使用隱式許可時(shí)的重要安全注意事項(xiàng)。
4.2.1. 授權(quán)請(qǐng)求
客戶端通過按附錄B使用“application/x-www-form-urlencoded”格式向授權(quán)端點(diǎn)URI的查詢部分添加下列參數(shù)構(gòu)造請(qǐng)求URI：
- response_type
必需的。值必須設(shè)置為“token”。
- client_id
必需的。如2.2節(jié)所述的客戶端標(biāo)識(shí)。
- redirect_uri
可選的。如3.1.2節(jié)所述。
- scope
可選的。如3.3節(jié)所述的訪問請(qǐng)求的范圍。
- state
推薦的。客戶度用于維護(hù)請(qǐng)求和回調(diào)之間的狀態(tài)的不透明的值。當(dāng)重定向用戶代理回到客戶端時(shí)，授權(quán)服務(wù)器包含此值。該參數(shù)應(yīng)該用于防止如10.12所述的跨站點(diǎn)請(qǐng)求偽造。
客戶端使用HTTP重定向響應(yīng)向構(gòu)造的URI定向資源所有者，或者通過經(jīng)由用戶代理至該URI的其他可用方法。
例如，客戶端使用TLS定向用戶代理發(fā)起下述HTTP請(qǐng)求（額外的換行僅用于顯示目的）：
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1Host: server.
授權(quán)服務(wù)器驗(yàn)證該請(qǐng)求，確保所有需要的參數(shù)已提交且有效。授權(quán)服務(wù)器必須驗(yàn)證它將重定向訪問令牌的重定向URI與如3.1.2節(jié)所述的客戶端注冊(cè)的重定向URI匹配。
如果請(qǐng)求是有效的，授權(quán)服務(wù)器對(duì)資源所有者進(jìn)行身份驗(yàn)證并獲得授權(quán)決定（通過詢問資源所有者或通過經(jīng)由其他方式確定批準(zhǔn)）。
當(dāng)確定決定后，授權(quán)服務(wù)器使用HTTP重定向響應(yīng)向提供的客戶端重定向URI定向用戶代理，或者通過經(jīng)由用戶代理至該URI的其他可行方法。
4.2.2. 訪問令牌響應(yīng)
如果資源所有者許可訪問請(qǐng)求，授權(quán)服務(wù)器頒發(fā)訪問令牌，通過使用按附錄B的“application/x-www-form-urlencoded”格式向重定向URI的片段部分添加下列參數(shù)傳遞訪問令牌至客戶端：
- access_token
必需的。授權(quán)服務(wù)器頒發(fā)的訪問令牌。
- token_type
必需的。如7.1節(jié)所述的頒發(fā)的令牌的類型。值是大小寫敏感的。
- expires_in
推薦的。以秒為單位的訪問令牌生命周期。例如，值“3600”表示訪問令牌將在從生成響應(yīng)時(shí)的1小時(shí)后到期。如果省略，則授權(quán)服務(wù)器應(yīng)該通過其他方式提供過期時(shí)間，或者記錄默認(rèn)值。
- scope
可選的，若與客戶端請(qǐng)求的范圍相同；否則，是必需的。如3.3節(jié)所述的訪問令牌的范圍。
- state
必需的，若“state”參數(shù)在客戶端授權(quán)請(qǐng)求中提交。從客戶端接收的精確值。授權(quán)服務(wù)器不能頒發(fā)刷新令牌。
例如，授權(quán)服務(wù)器通過發(fā)送以下HTTP響應(yīng)重定向用戶代理：（額外的換行符僅用于顯示目的）：
HTTP/1.1 302 FoundLocation: http:///cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600
開發(fā)人員應(yīng)注意，一些用戶代理不支持在HTTP“Location”HTTP響應(yīng)標(biāo)頭字段中包含片段組成部分。這些客戶端需要使用除了3xx重定向響應(yīng)以外的其他方法來重定向客戶端——-例如，返回一個(gè)HTML頁面，其中包含一個(gè)具有鏈接到重定向URI的動(dòng)作的“繼續(xù)”按鈕。
客戶端必須忽略無法識(shí)別的響應(yīng)參數(shù)。本規(guī)范未定義授權(quán)碼字符串大小?？蛻舳藨?yīng)該避免假設(shè)代碼值的長度。 授權(quán)服務(wù)器應(yīng)記錄其發(fā)放的任何值的大小。
- 4.2.2.1.錯(cuò)誤響應(yīng)
4.2.2.1. 錯(cuò)誤響應(yīng)
如果由于缺失、無效或不匹配的重定向URI而請(qǐng)求失敗，或者如果客戶端表示缺失或無效，授權(quán)服務(wù)器應(yīng)該通知資源所有者該錯(cuò)誤且不能向無效的重定向URI自動(dòng)重定向用戶代理。
如果資源所有者拒絕訪問請(qǐng)求，或者如果請(qǐng)求因?yàn)槠渌侨笔Щ驘o效重定向URI原因而失敗，授權(quán)服務(wù)器通過按附錄B使用“application/x-www-form-urlencoded”格式向重定向URI的片段部分添加下列參數(shù)通知客戶端：
-
error
必需的。下列ASCII[USASCII]錯(cuò)誤代碼之一：
- invalid_request
請(qǐng)求缺少必需的參數(shù)、包含無效的參數(shù)值、包含一個(gè)參數(shù)超過一次或其他不良格式。
- unauthorized_client
客戶端未被授權(quán)使用此方法請(qǐng)求授權(quán)碼。
- access_denied
資源所有者或授權(quán)服務(wù)器拒絕該請(qǐng)求。
- unsupported_response_type
授權(quán)服務(wù)器不支持使用此方法獲得授權(quán)碼。
- invalid_scope
請(qǐng)求的范圍無效，未知的或格式不正確。
- server_error
授權(quán)服務(wù)器遇到意外情況導(dǎo)致其無法執(zhí)行該請(qǐng)求。（此錯(cuò)誤代碼是必要的，因?yàn)?00內(nèi)部服務(wù)器錯(cuò)誤HTTP狀態(tài)代碼不能由HTTP重定向返回給客戶端）。
- temporarily_unavailable
授權(quán)服務(wù)器由于暫時(shí)超載或服務(wù)器維護(hù)目前無法處理請(qǐng)求。 （此錯(cuò)誤代碼是必要的，因?yàn)?03服務(wù)不可用HTTP狀態(tài)代碼不可以由HTTP重定向返回給客戶端）。
“error”參數(shù)的值不能包含集合％x20-21 /％x23-5B /％x5D-7E以外的字符。
-
error_description
可選的。提供額外信息的人類可讀的ASCII[USASCII]文本，用于協(xié)助客戶端開發(fā)人員理解所發(fā)生的錯(cuò)誤。
“error_description”參數(shù)的值不能包含集合％x20-21 /％x23-5B /％x5D-7E以外的字符。
-
error_uri
可選的。指向帶有有關(guān)錯(cuò)誤的信息的人類可讀網(wǎng)頁的URI，用于提供客戶端開發(fā)人員關(guān)于該錯(cuò)誤的額外信息。
“error_uri”參數(shù)值必須符合URI參考語法，因此不能包含集合％x21/%x23-5B /％x5D-7E以外的字符。
- state
必需的，若“state”參數(shù)在客戶端授權(quán)請(qǐng)求中提交。從客戶端接收的精確值。
例如，授權(quán)服務(wù)器通過發(fā)送以下HTTP響應(yīng)重定向用戶代理：
HTTP/1.1 302 FoundLocation: https://client./cb#error=access_denied&state=xyz
4.3. 資源所有者密碼憑據(jù)許可
資源所有者密碼憑據(jù)許可類型適合于資源所有者與客戶端具有信任關(guān)系的情況，如設(shè)備操作系統(tǒng)或高級(jí)特權(quán)應(yīng)用。當(dāng)啟用這種許可類型時(shí)授權(quán)服務(wù)器應(yīng)該特別關(guān)照且只有當(dāng)其他流程都不可用時(shí)才可以。
這種許可類型適合于能夠獲得資源所有者憑據(jù)（用戶名和密碼，通常使用交互的形式）的客戶端。通過轉(zhuǎn)換已存儲(chǔ)的憑據(jù)至訪問令牌，它也用于遷移現(xiàn)存的使用如HTTP基本或摘要身份驗(yàn)證的直接身份驗(yàn)證方案的客戶端至OAuth。
+----------+ | Resource | | Owner | | | +----------+ v | Resource Owner (A) Password Credentials | v +---------+ +---------------+ | |>--(B)---- Resource Owner ------->| | | | Password Credentials | Authorization | | Client | | Server | | |<--(C)---- Access Token ---------<| | | | (w/ Optional Refresh Token) | | +---------+ +---------------+
圖5：資源所有者密碼憑據(jù)流程
圖5中的所示流程包含以下步驟：
例如，客戶端使用傳輸層安全發(fā)起如下HTTP請(qǐng)求（額外的換行僅用于顯示目的）：
POST /token HTTP/1.1Host: server.Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type: application/x-www-form-urlencodedgrant_type=password&username=johndoe&password=A3ddj3w
授權(quán)服務(wù)器必須：
- 要求機(jī)密客戶端或任何被頒發(fā)了客戶端憑據(jù)（或有其他身份驗(yàn)證要求）的客戶端進(jìn)行客戶端身份驗(yàn)證，
- 若包括了客戶端身份驗(yàn)證，驗(yàn)證客戶端身份，并
- 使用它現(xiàn)有的密碼驗(yàn)證算法驗(yàn)證資源所有者的密碼憑據(jù)。
由于這種訪問令牌請(qǐng)求使用了資源所有者的密碼，授權(quán)服務(wù)器必須保護(hù)端點(diǎn)防止暴力攻擊（例如，使用速率限制或生成警報(bào)）。
4.3.3. 訪問令牌響應(yīng)
如果訪問令牌請(qǐng)求是有效的且被授權(quán)，授權(quán)服務(wù)器如5.1節(jié)所述頒發(fā)訪問令牌以及可選的刷新令牌。如果請(qǐng)求客戶端身份驗(yàn)證失敗或無效，授權(quán)服務(wù)器如5.2節(jié)所述的返回錯(cuò)誤響應(yīng)。
一個(gè)樣例成功響應(yīng)：
HTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: no-cache{ 'access_token':'2YotnFZFEjr1zCsicMWpAA', 'token_type':'example', 'expires_in':3600, 'refresh_token':'tGzv3JOkF0XG5Qx2TlKWIA', 'example_parameter':'example_value'}
4.4. 客戶端憑據(jù)許可
當(dāng)客戶端請(qǐng)求訪問它所控制的，或者事先與授權(quán)服務(wù)器協(xié)商（所采用的方法超出了本規(guī)范的范圍）的其他資源所有者的受保護(hù)資源，客戶端可以只使用它的客戶端憑據(jù)（或者其他受支持的身份驗(yàn)證方法）請(qǐng)求訪問令牌。
客戶端憑據(jù)許可類型必須只能由機(jī)密客戶端使用。
+---------+ +---------------+ | | | | | |>--(A)- Client Authentication --->| Authorization | | Client | | Server | | |<--(B)---- Access Token ---------<| | | | | | +---------+ +---------------+
圖6：客戶端憑證流程
圖6中的所示流程包含以下步驟：
客戶端必須如3.2.1所述與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證。
例如，客戶端使用傳輸層安全發(fā)起如下HTTP請(qǐng)求（額外的換行僅用于顯示目的）：
POST /token HTTP/1.1Host: server.Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type: application/x-www-form-urlencodedgrant_type=client_credentials
授權(quán)服務(wù)器必須對(duì)客戶端進(jìn)行身份驗(yàn)證。
4.4.3. 訪問令牌響應(yīng)
如果訪問令牌請(qǐng)求是有效的且被授權(quán)，授權(quán)服務(wù)器如5.1節(jié)所述頒發(fā)訪問令牌以及可選的刷新令牌。刷新令牌不應(yīng)該包含在內(nèi)。 如果請(qǐng)求因客戶端身份驗(yàn)證失敗或無效，授權(quán)服務(wù)器如5.2節(jié)所述的返回錯(cuò)誤響應(yīng)。
一個(gè)樣例成功響應(yīng)：
HTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: no-cache{ 'access_token':'2YotnFZFEjr1zCsicMWpAA', 'token_type':'example', 'expires_in':3600， 'example_parameter':'example_value'}
4.5. 擴(kuò)展許可
通過使用絕對(duì)URI作為令牌端點(diǎn)的“grant_type”參數(shù)的值指定許可類型，并通過添加任何其他需要的參數(shù)，客戶端使用擴(kuò)展許可類型。
例如，采用[OAuth-SAML]定義的安全斷言標(biāo)記語言（SAML）2.0斷言許可類型請(qǐng)求訪問令牌，客戶端可以使用TLS發(fā)起如下的HTTP請(qǐng)求（額外的換行僅用于顯示目的）：
POST /token HTTP/1.1Host: server.Content-Type: application/x-www-form-urlencodedgrant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU[...為簡潔起見省略...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
如果訪問令牌請(qǐng)求是有效的且被授權(quán)，授權(quán)服務(wù)器如5.1節(jié)所述頒發(fā)訪問令牌以及可選的刷新令牌。如果請(qǐng)求因客戶端身份驗(yàn)證失敗或無效，授權(quán)服務(wù)器如5.2節(jié)所述的返回錯(cuò)誤響應(yīng)。
5. 頒發(fā)訪問令牌
如果訪問令牌請(qǐng)求是有效的且被授權(quán)，授權(quán)服務(wù)器如5.1節(jié)所述頒發(fā)訪問令牌以及可選的刷新令牌。如果請(qǐng)求因客戶端身份驗(yàn)證失敗或無效，授權(quán)服務(wù)器如5.2節(jié)所述的返回錯(cuò)誤響應(yīng)。
- 5.1.成功響應(yīng)
- 5.2.錯(cuò)誤響應(yīng)
5.1. 成功的響應(yīng)
授權(quán)服務(wù)器頒發(fā)訪問令牌和可選的刷新令牌，通過向HTTP響應(yīng)實(shí)體正文中添加下列參數(shù)并使用200（OK）狀態(tài)碼構(gòu)造響應(yīng)：
- access_token
必需的。授權(quán)服務(wù)器頒發(fā)的訪問令牌。
- token_type
必需的。如7.1節(jié)所述的頒發(fā)的令牌的類型。值是大小寫敏感的。
- expires_in
推薦的。以秒為單位的訪問令牌生命周期。例如，值“3600”表示訪問令牌將在從生成響應(yīng)時(shí)的1小時(shí)后到期。如果省略，則授權(quán)服務(wù)器應(yīng)該通過其他方式提供過期時(shí)間，或者記錄默認(rèn)值。
- refresh_token
可選的。刷新令牌，可以用于如第6節(jié)所述使用相同的授權(quán)許可獲得新的訪問令牌。
- scope
可選的，若與客戶端請(qǐng)求的范圍相同；否則，必需的。如3.3節(jié)所述的訪問令牌的范圍。
這些參數(shù)使用RFC4627定義的“application/json”媒體類型包含在HTTP響應(yīng)實(shí)體正文中。通過將每個(gè)參數(shù)添加到最高結(jié)構(gòu)級(jí)別， 參數(shù)被序列化為JavaScript對(duì)象表示法（JSON）的結(jié)構(gòu)。參數(shù)名稱和字符串值作為JSON字符串類型包含。數(shù)值的值作為JSON數(shù)字類型包含。參數(shù)順序無關(guān)并可以變化。
在任何包含令牌、憑據(jù)或其他敏感信息的響應(yīng)中，授權(quán)服務(wù)器必須在其中包含值為“no-store”的HTTP“Cache-Control”響應(yīng)頭部域RFC2616，和值為“no-cache”的“Pragma”響應(yīng)頭部域RFC2616。例如：
HTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: no-cache{ 'access_token':'2YotnFZFEjr1zCsicMWpAA', 'token_type':'example', 'expires_in':3600, 'refresh_token':'tGzv3JOkF0XG5Qx2TlKWIA', 'example_parameter':'example_value'}
客戶端必須忽略響應(yīng)中不能識(shí)別的值的名稱。令牌和從授權(quán)服務(wù)器接收到的值的大小未定義?？蛻舳藨?yīng)該避免對(duì)值的大小做假設(shè)。授權(quán)服務(wù)器應(yīng)記錄其發(fā)放的任何值的大小。
5.2. 錯(cuò)誤響應(yīng)
授權(quán)服務(wù)器使用HTTP 400（錯(cuò)誤請(qǐng)求）狀態(tài)碼響應(yīng)，在響應(yīng)中包含下列參數(shù)：
這些參數(shù)使用RFC4627定義的“application/json”媒體類型包含在HTTP響應(yīng)實(shí)體正文中。通過將每個(gè)參數(shù)添加到最高結(jié)構(gòu)級(jí)別， 參數(shù)被序列化為JavaScript對(duì)象表示法（JSON）的結(jié)構(gòu)。參數(shù)名稱和字符串值作為JSON字符串類型包含。數(shù)值的值作為JSON數(shù)字類型包含。參數(shù)順序無關(guān)并可以變化。例如：
HTTP/1.1 400 Bad RequestContent-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: no-cache{ 'error':'invalid_request'}
6. 刷新訪問令牌
若授權(quán)服務(wù)器給客戶端頒發(fā)了刷新令牌，客戶端通過使用按附錄B“application/x-www-form-urlencoded”格式在HTTP請(qǐng)求實(shí)體正文中發(fā)送下列UTF-8字符編碼的參數(shù)向令牌端點(diǎn)發(fā)起刷新請(qǐng)求：
- grant_type
必需的。值必須設(shè)置為“refresh_token”。
- refresh_token
必需的。頒發(fā)給客戶端的刷新令牌。
- scope
可選的。如3.3節(jié)所述的訪問請(qǐng)求的范圍。請(qǐng)求的范圍不能包含任何不是由資源所有者原始許可的范圍，若省略，被視為與資源所有者原始許可的范圍相同。
因?yàn)樗⑿铝钆仆ǔＪ怯糜谡?qǐng)求額外的訪問令牌的持久憑證，刷新令牌綁定到被它被頒發(fā)給的客戶端。如果客戶端類型是機(jī)密的或客戶端被頒發(fā)了客戶端憑據(jù)（或選定的其他身份驗(yàn)證要求），客戶端必須如3.2.1節(jié)所述與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證。
例如，客戶端使用傳輸層安全發(fā)起如下HTTP請(qǐng)求（額外的換行僅用于顯示目的）：
POST /token HTTP/1.1Host: server.Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type: application/x-www-form-urlencodedgrant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
授權(quán)服務(wù)器必須：
- 要求機(jī)密客戶端或任何被頒發(fā)了客戶端憑據(jù)（或有其他身份驗(yàn)證要求）的客戶端進(jìn)行客戶端身份驗(yàn)證，
- 若包括了客戶端身份驗(yàn)證，驗(yàn)證客戶端身份并確保刷新令牌是被頒發(fā)給進(jìn)行身份驗(yàn)證的客戶端的，并
- 驗(yàn)證刷新令牌。
如果有效且被授權(quán)，授權(quán)服務(wù)器如5.1節(jié)所述頒發(fā)訪問令牌。如果請(qǐng)求因驗(yàn)證失敗或無效，授權(quán)服務(wù)器5.2節(jié)所述返回錯(cuò)誤響應(yīng)。
授權(quán)服務(wù)器可以頒發(fā)新的刷新令牌，在這種情況下，客戶端必須放棄舊的刷新令牌，替換為新的刷新令牌。在向客戶端頒發(fā)新的刷新令牌后授權(quán)服務(wù)器可以撤銷舊的刷新令牌。若頒發(fā)了新的刷新令牌，刷新令牌的范圍必須與客戶端包含在請(qǐng)求中的刷新令牌的范圍相同。
7. 訪問受保護(hù)資源
通過向資源服務(wù)器出示訪問令牌，客戶端訪問受保護(hù)資源。資源服務(wù)器必須驗(yàn)證訪問令牌，并確保它沒有過期且其范圍涵蓋了請(qǐng)求的資源。資源服務(wù)器用于驗(yàn)證訪問令牌的方法（以及任何錯(cuò)誤響應(yīng)）超出了本規(guī)范的范圍，但一般包括資源服務(wù)器和授權(quán)服務(wù)器之間的互動(dòng)或協(xié)調(diào)。
客戶端使用訪問令牌與資源服務(wù)器進(jìn)行證認(rèn)的方法依賴于授權(quán)服務(wù)器頒發(fā)的訪問令牌的類型。通常，它涉及到使用具有所采用的訪問令牌類型的規(guī)范定義的身份驗(yàn)證方案(如RFC6750)的HTTP“Authorization”的請(qǐng)求標(biāo)頭字段RFC2617。
7.1. 訪問令牌類型
訪問令牌的類型給客戶端提供了成功使用該訪問令牌（和類型指定的屬性）發(fā)起受保護(hù)資源請(qǐng)求所需的信息 若客戶端不理解令牌類型，則不能使用該訪問令牌。
例如，RFC6750定義的“bearer”令牌類型簡單的在請(qǐng)求中包含訪問令牌字符串來使用：
GET /resource/1 HTTP/1.1Host: Authorization: Bearer F_9.B5f-4.1JqM
而[OAuth-HTTP-MAC]定義的“mac”令牌類型通過與許可類型一起頒發(fā)用于對(duì)HTTP請(qǐng)求中某些部分簽名的消息認(rèn)證碼（MAC）的密鑰來使用。
GET /resource/1 HTTP/1.1Host: Authorization: MAC id='h480djs93hd8',nonce='274312:dj83hs9s',mac='kDZvddkndxvhGRXZhvuDjEWhGeE='
提供上面的例子僅作說明用途。建議開發(fā)人員在使用前查閱RFC6750和[OAuth-HTTP-MAC]規(guī)范。
每一種訪問令牌類型的定義指定與“access_token”響應(yīng)參數(shù)一起發(fā)送到客戶端的額外屬性。它還定義了HTTP驗(yàn)證方法當(dāng)請(qǐng)求受保護(hù)資源時(shí)用于包含訪問令牌。
7.2. 錯(cuò)誤響應(yīng)
如果資源訪問請(qǐng)求失敗，資源服務(wù)器應(yīng)該通知客戶端該錯(cuò)誤。雖然規(guī)定這些錯(cuò)誤響應(yīng)超出了本規(guī)范的范圍，但是本文檔在11.4節(jié)建立了一張公共注冊(cè)表，用作OAuth令牌身份驗(yàn)證方案之間分享的錯(cuò)誤值。
主要為OAuth令牌身份驗(yàn)證設(shè)計(jì)的新身份驗(yàn)證方案應(yīng)該定義向客戶端提供錯(cuò)誤狀態(tài)碼的機(jī)制，其中允許的錯(cuò)誤值限于本規(guī)范建立的錯(cuò)誤注冊(cè)表中。
這些方案可以限制有效的錯(cuò)誤代碼是注冊(cè)值的子集。如果錯(cuò)誤代碼使用命名參數(shù)返回，該參數(shù)名稱應(yīng)該是“error”。
其他能夠被用于OAuth令牌身份驗(yàn)證的方案，但不是主要為此目的而設(shè)計(jì)的，可以幫頂他們的錯(cuò)誤值到相同方式的注冊(cè)表項(xiàng)。
新的認(rèn)證方案也可以選擇指定使用“error_description”和'error_uri'參數(shù)，用于以本文檔中用法相同的方式的返回錯(cuò)誤信息。
8. 可擴(kuò)展性
采用URI命名的類型應(yīng)該限定于特定供應(yīng)商的實(shí)現(xiàn)，它們不是普遍適用的并且特定于使用它們的資源服務(wù)器的實(shí)現(xiàn)細(xì)節(jié)。
所有其他類型都必須注冊(cè)。類型名稱必需符合type-name ANBF。如果類型定義包含了一種新的HTTP身份驗(yàn)證方案，該類型名稱應(yīng)該與該HTTP身份驗(yàn)證方案名稱一致（如RFC2617定義）。令牌類型“example”被保留用于樣例中。
type-name = 1*name-charname-char = '-' / '.' / '_' / DIGIT / ALPHA
8.2. 定義新的端點(diǎn)參數(shù)
用于授權(quán)端點(diǎn)或令牌端點(diǎn)的新的請(qǐng)求或響應(yīng)參數(shù)按照11.2節(jié)中的過程在OAuth參數(shù)注冊(cè)表中定義和注冊(cè)。
參數(shù)名稱必須符合param-name ABNF，并且參數(shù)值的語法必須是明確定義的（例如，使用ABNF，或現(xiàn)有參數(shù)的語法的引用）。
param-name = 1*name-charname-char = '-' / '.' / '_' / DIGIT / ALPHA
不是普遍適用的并且特定于使用它們的授權(quán)服務(wù)器的實(shí)現(xiàn)細(xì)節(jié)的未注冊(cè)的特定供應(yīng)商的參數(shù)擴(kuò)展應(yīng)該采用特定供應(yīng)商的前綴（例如，以“companyname_”開頭），從而不會(huì)與其他已注冊(cè)的值沖突。
8.3. 定義新的授權(quán)許可類型
新的授權(quán)許可類型可以通過賦予它們一個(gè)“grant_type”參數(shù)使用的唯一的絕對(duì)URI來定義。如果擴(kuò)展許可類型需要其他令牌端點(diǎn)參數(shù)，它們必須如11.2節(jié)所述在OAuth參數(shù)注冊(cè)表中注冊(cè)。
8.4. 定義新的授權(quán)端點(diǎn)響應(yīng)類型
用于授權(quán)端點(diǎn)的新的響應(yīng)類型按照11.3節(jié)中的過程在授權(quán)端點(diǎn)響應(yīng)類型注冊(cè)表中定義和注冊(cè)。響應(yīng)類型名稱必須符合response-type ABNF。
response-type = response-name *( SP response-name )response-name = 1*response-charresponse-char = '_' / DIGIT / ALPHA
如果響應(yīng)類型包含一個(gè)或多個(gè)空格字符（%x20），它被看作是一個(gè)空格分隔的值列表，其中的值的順序不重要。只有一種值的順序可以被注冊(cè)，它涵蓋了相同的值的集合的所有其他排列。
例如，響應(yīng)類型“token code”未由本規(guī)范定義。然而，一個(gè)擴(kuò)展可以定義和注冊(cè)“token code”響應(yīng)類型。 一旦注冊(cè)，相同的組合“code token”不能被注冊(cè)，但是這兩個(gè)值都可以用于表示相同的響應(yīng)類型。
8.5. 定義其他錯(cuò)誤代碼
在協(xié)議擴(kuò)展（例如，訪問令牌類型、擴(kuò)展參數(shù)或擴(kuò)展許可類型等）需要其他錯(cuò)誤代碼用于授權(quán)碼許可錯(cuò)誤響應(yīng)（4.1.2.1節(jié)）、隱式許可錯(cuò)誤響應(yīng)（4.2.2.1節(jié)）、令牌錯(cuò)誤響應(yīng)（5.2節(jié)）或資源訪問錯(cuò)誤響應(yīng)（7.2節(jié)）的情況下，這些錯(cuò)誤代碼可以被定義。
如果用于與它們配合的擴(kuò)展是已注冊(cè)的訪問令牌類型，已注冊(cè)的端點(diǎn)參數(shù)或者擴(kuò)展許可類型，擴(kuò)展錯(cuò)誤代碼必須被注冊(cè)。用于未注冊(cè)擴(kuò)展的錯(cuò)誤代碼可以被注冊(cè)。
錯(cuò)誤代碼必須符合的error ABNF，且可能的話應(yīng)該以一致的名稱作前綴。例如，一個(gè)表示給擴(kuò)展參數(shù)“example”設(shè)置了無效值的錯(cuò)誤應(yīng)該被命名為“example_invalid”。
error = 1*error-char error-char = %x20-21 / %x23-5B / %x5D-7E
9. 本機(jī)應(yīng)用程序
本機(jī)應(yīng)用程序是安裝和執(zhí)行在資源所有者使用的設(shè)備上的客戶端（例如，桌面程序，本機(jī)移動(dòng)應(yīng)用）。本機(jī)應(yīng)用程序需要關(guān)于安全、平臺(tái)能力和整體最終用戶體驗(yàn)的特別注意事項(xiàng)。
授權(quán)端點(diǎn)需要在客戶端和資源所有者用戶代理之間進(jìn)行交互。本機(jī)應(yīng)用程序可以調(diào)用外部的用戶代理，或在應(yīng)用程序中嵌入用戶代理。例如：
- 外部用戶代理-本機(jī)應(yīng)用程序可以捕獲來自授權(quán)服務(wù)器的響應(yīng)。它可以使用帶有操作系統(tǒng)已注冊(cè)方案的重定向URI調(diào)用客戶端作為處理程序，手動(dòng)復(fù)制粘貼憑據(jù)，運(yùn)行本地Web服務(wù)器，安裝用戶代理擴(kuò)展，或者通過提供重定向URI來指定客戶端控制下的服務(wù)器托管資源，反過來使響應(yīng)對(duì)本機(jī)應(yīng)用程序可用。
- 嵌入式用戶代理-通過監(jiān)視資源加載過程中發(fā)生的狀態(tài)變化或者訪問用戶代理的cookies存儲(chǔ)，本機(jī)應(yīng)用程序直接與嵌入式用戶代理通信，獲得響應(yīng)。
當(dāng)在外部或嵌入式用戶代理中選擇時(shí)，開發(fā)者應(yīng)該考慮如下：
- 外部用戶代理可能會(huì)提高完成率，因?yàn)橘Y源所有者可能已經(jīng)有了與授權(quán)服務(wù)器的活動(dòng)會(huì)話，避免了重新進(jìn)行身份驗(yàn)證的需要。它提供了熟悉的最終用戶體驗(yàn)和功能。資源所有者可能也依賴于用戶代理特性或擴(kuò)展幫助他進(jìn)行身份驗(yàn)證（例如密碼管理器、兩步設(shè)備讀取器）
- 嵌入式用戶代理可能會(huì)提供更好的可用性，因?yàn)樗苊饬饲袚Q上下文和打開新窗口的需要。
- 嵌入式用戶代理構(gòu)成了安全挑戰(zhàn)，因?yàn)橘Y源所有者在一個(gè)未識(shí)別的窗口中進(jìn)行身份驗(yàn)證，無法獲得在大多數(shù)外部用戶代理中的可視的保護(hù)。嵌入式用戶代理教育用戶信任未標(biāo)識(shí)身份驗(yàn)證請(qǐng)求（使釣魚攻擊更易于實(shí)施）。
當(dāng)在隱式許可類型和授權(quán)碼許可類型中選擇時(shí)，下列應(yīng)該被考慮：
- 使用授權(quán)碼許可類型的本機(jī)應(yīng)用程序應(yīng)該這么做而不需使用用戶憑據(jù)，因?yàn)楸緳C(jī)應(yīng)用程序無力保持客戶端憑據(jù)的機(jī)密性。
- 當(dāng)使用隱式許可類型流程時(shí)，刷新令牌不會(huì)返回，這就要求一旦訪問令牌過期就要重復(fù)授權(quán)過程。
10. 安全考量
作為一個(gè)靈活的可擴(kuò)展的框架，OAuth的安全性考量依賴于許多因素。 以下小節(jié)提為實(shí)現(xiàn)者提供了聚焦在2.1節(jié)所述的三種客戶端配置上的安全指南：Web應(yīng)用、基于用戶代理的應(yīng)用和本地應(yīng)用程序。
全面的OAuth安全模型和分析以及該協(xié)議設(shè)計(jì)的背景在[OAuth-THREATMODE]中提供。
授權(quán)不得向本地應(yīng)用程序或基于用戶代理的應(yīng)用客戶端頒發(fā)客戶端密碼或其他客戶端憑據(jù)用于客戶端驗(yàn)證目的。授權(quán)服務(wù)器可以頒發(fā)客戶端密碼或其他憑據(jù)給專門的設(shè)備上特定安裝的本地應(yīng)用程序客戶端。
當(dāng)客戶端身份驗(yàn)證不可用時(shí)，授權(quán)服務(wù)器應(yīng)該采用其他方式來驗(yàn)證客戶端的身份-例如，通過要求客戶端重定向URI的注冊(cè)或者引入資源所有者來確認(rèn)身份。當(dāng)請(qǐng)求資源所有者授權(quán)時(shí)，有效的重定向URI是不足以驗(yàn)證客戶端的身份，但可以用來防止在獲得資源所有者授權(quán)后將憑據(jù)傳遞給假冒的客戶端。
授權(quán)服務(wù)器必須考慮與未進(jìn)行身份驗(yàn)證的客戶端交互的安全實(shí)現(xiàn)并采取措施限制頒發(fā)給這些客戶端的其他憑據(jù)（如刷新令牌）的潛在泄露。
10.2. 客戶端仿冒
如果被仿冒的客戶端不能，或無法保持其客戶端憑據(jù)保密。惡意客戶端可能冒充其他客戶端，并獲得對(duì)受保護(hù)資源的訪問權(quán)限。
授權(quán)服務(wù)器任何可能的時(shí)候必須驗(yàn)證客戶端身份。如果授權(quán)服務(wù)器由于客戶端的性質(zhì)無法對(duì)客戶端進(jìn)行身份驗(yàn)證，授權(quán)服務(wù)器必須要求注冊(cè)任何用于接收授權(quán)響應(yīng)的重定向URI并且應(yīng)該利用其他手段保護(hù)資源所有者防止這樣的潛在仿冒客戶端。例如，授權(quán)服務(wù)器可以引入資源所有者來幫助識(shí)別客戶端和它的來源。
授權(quán)服務(wù)器應(yīng)該實(shí)施顯式的資源所有者身份驗(yàn)證并且提供給資源所有者有關(guān)客戶端及其請(qǐng)求的授權(quán)范圍和生命周期的信息。由資源所有者在當(dāng)前客戶端上下文中審查信息并授權(quán)或拒絕該請(qǐng)求。
授權(quán)服務(wù)器未對(duì)客戶端進(jìn)行身份驗(yàn)證（沒有活動(dòng)的資源所有者交互）或未依靠其他手段確保重復(fù)的請(qǐng)求來自于原始客戶端而非冒充者時(shí)，不應(yīng)該自動(dòng)處理重復(fù)的授權(quán)請(qǐng)求。
10.3. 訪問令牌
訪問令牌憑據(jù)（以及任何機(jī)密的訪問令牌屬性）在傳輸和儲(chǔ)存時(shí)必須保持機(jī)密性，并只與授權(quán)服務(wù)器、訪問令牌生效的資源服務(wù)器和訪問令牌被頒發(fā)的客戶端共享。訪問令牌憑據(jù)必須只能使用帶有RFC2818定義的服務(wù)器身份驗(yàn)證的1.6節(jié)所述的TLS 傳輸。
當(dāng)使用隱式授權(quán)許可類型時(shí)，訪問令牌在URI片段中傳輸，這可能泄露訪問令牌給未授權(quán)的一方。
授權(quán)服務(wù)器必須確保訪問令牌不能被生成、修改或被未授權(quán)一方猜測而產(chǎn)生有效的訪問令牌。
客戶端應(yīng)該為最小范圍的需要請(qǐng)求訪問令牌。授權(quán)服務(wù)器在選擇如何兌現(xiàn)請(qǐng)求的范圍時(shí)應(yīng)該將客戶端身份考慮在內(nèi)，且可以頒發(fā)具有比請(qǐng)求的更少的權(quán)限的訪問令牌。
本規(guī)范未給資源服務(wù)器提供任何方法來確保特定的客戶端提交給它的訪問令牌是授權(quán)服務(wù)器頒發(fā)給此客戶端的。
10.4. 刷新令牌
授權(quán)服務(wù)器可以給Web應(yīng)用客戶端和本機(jī)應(yīng)用程序客戶端頒發(fā)刷新令牌。
刷新令牌在傳輸和儲(chǔ)存時(shí)必須保持機(jī)密性，并只與授權(quán)服務(wù)器和刷新令牌被頒發(fā)的客戶端共享。授權(quán)服務(wù)器必須維護(hù)刷新令牌和它被頒發(fā)給的客戶端之間的綁定。刷新令牌必須只能使用帶有RFC2818定義的服務(wù)器身份驗(yàn)證的1.6所述的TLS 傳輸。
授權(quán)服務(wù)器必須驗(yàn)證刷新令牌和客戶端身份之間的綁定，無論客戶端身份是否能被驗(yàn)證。當(dāng)無法進(jìn)行客戶端身份驗(yàn)證時(shí)，授權(quán)服務(wù)器應(yīng)該采取其他手段檢測刷新令牌濫用。
例如，授權(quán)服務(wù)器可以使用刷新令牌輪轉(zhuǎn)機(jī)制，隨著每次訪問令牌刷新響應(yīng)，新的刷新令牌被頒發(fā)。以前的刷新令牌被作廢但是由授權(quán)服務(wù)器保留。如果刷新令牌被泄露，隨后同時(shí)被攻擊者和合法客戶端使用，他們中一人將提交被作廢的刷新令牌，這將通知入侵給授權(quán)服務(wù)器。
授權(quán)服務(wù)器必須確保刷新令牌不能被生成、修改或被未授權(quán)一方猜測而產(chǎn)生有效的刷新令牌。
10.5. 授權(quán)碼
授權(quán)碼的傳輸應(yīng)該建立在安全通道上，客戶端應(yīng)該要求在它的重定向URI上使用TLS，若該URI指示了一個(gè)網(wǎng)絡(luò)資源。 由于授權(quán)碼由用戶代理重定向傳輸，它們可能潛在地通過用戶代理歷史記錄和HTTP參照標(biāo)頭被泄露。
授權(quán)碼明以純文本承載憑據(jù)使用，用于驗(yàn)證在授權(quán)服務(wù)器許可權(quán)限的資源所有者就是返回到客戶端完成此過程的相同的資源所有者。因此，如果客戶端依賴于授權(quán)碼作為它自己的資源所有者身份驗(yàn)證，客戶端重定向端點(diǎn)必須要求使用TLS。
授權(quán)碼必須是短暫的且是單用戶的。如果授權(quán)服務(wù)器觀察到多次以授權(quán)碼交換訪問令牌的嘗試，授權(quán)服務(wù)器應(yīng)該試圖吊銷所有基于泄露的授權(quán)碼而頒發(fā)的訪問令牌。
如果客戶端可以進(jìn)行身份驗(yàn)證，授權(quán)服務(wù)器必須驗(yàn)證客戶端身份，并確保授權(quán)碼頒發(fā)給了同一個(gè)客戶端。
10.6. 授權(quán)碼重定向URI偽造
當(dāng)使用授權(quán)碼許可類型請(qǐng)求授權(quán)時(shí)，客戶端可以通過“redirect_uri”參數(shù)指定重定向URI。 如果攻擊者能夠偽造重定向URI的值，這可能導(dǎo)致授權(quán)服務(wù)器向攻擊者控制的URI重定向帶有授權(quán)碼的資源所有者用戶代理。
攻擊者可以在合法客戶端上創(chuàng)建一個(gè)帳戶，并開始授權(quán)流程。當(dāng)攻擊者的用戶代理被發(fā)送到授權(quán)服務(wù)器來許可訪問權(quán)限時(shí)，攻擊者抓取合法客戶端提供的授權(quán)URI并用攻擊者控制下的URI替換客戶端的重定向URI。 攻擊者然后欺騙受害者順著仿冒的鏈接來對(duì)合法客戶端授權(quán)訪問權(quán)限。
一旦在授權(quán)服務(wù)器——受害者被唆使代表一個(gè)合法的被信任的客戶端使用正常有效的請(qǐng)求——授權(quán)該請(qǐng)求時(shí)。受害者然后帶著授權(quán)碼重定向到受攻擊者控制的端點(diǎn)。通過使用客戶端提交的原始重定向URI向客戶端發(fā)送授權(quán)碼，攻擊者完成授權(quán)流程?？蛻舳擞檬跈?quán)碼交換訪問令牌并與將它與攻擊者的客戶端賬號(hào)關(guān)聯(lián)，該賬戶現(xiàn)在能獲得受害者授權(quán)的（通過客戶端）對(duì)訪問受保護(hù)資源的訪問權(quán)限。
為了防止這種攻擊，授權(quán)服務(wù)器必須確保用于獲得授權(quán)碼的重定向URI與當(dāng)用授權(quán)碼交換訪問令牌時(shí)提供的重定向URI相同。授權(quán)服務(wù)器必須要求公共客戶端，并且應(yīng)該要求機(jī)密客戶注冊(cè)它們的重定向URI。如果在請(qǐng)求中提供一個(gè)重定向URI，授權(quán)服務(wù)器必須驗(yàn)證對(duì)注冊(cè)的值。如果在請(qǐng)求中提供了重定向URI，授權(quán)服務(wù)器必須對(duì)比已注冊(cè)的。
10.7. 資源所有者密碼憑據(jù)
資源所有者密碼憑據(jù)許可類型通常用于遺留或遷移原因。它降低了由客戶端存儲(chǔ)用戶名和密碼的整體風(fēng)險(xiǎn)，但并沒有消除泄露高度特權(quán)的憑證給客戶端的需求。
這種許可類型比其他許可類型承載了更高的風(fēng)險(xiǎn)，因?yàn)樗Ａ袅吮緟f(xié)議尋求避免的密碼反模式。客戶端可能濫用密碼或密碼可能會(huì)無意中被泄露給攻擊者（例如，通過客戶端保存的日志文件或其他記錄）。
此外，由于資源擁有者對(duì)授權(quán)過程沒有控制權(quán)（在轉(zhuǎn)手它的憑據(jù)給客戶端后資源所有者的參與結(jié)束），客戶端可以獲得比資源所有者預(yù)期的具有更大范圍的訪問令牌。授權(quán)服務(wù)器應(yīng)該考慮由這種許可類型頒發(fā)的訪問令牌的范圍和壽命。
授權(quán)服務(wù)器和客戶端應(yīng)該盡量減少這種許可類型的使用，并盡可能采用其他許可類型。
10.8. 請(qǐng)求機(jī)密性
訪問令牌、刷新令牌、資源所有者密碼和客戶端憑據(jù)不能以明文傳輸。授權(quán)碼不應(yīng)該以明文傳輸。
“state”和“scope”參數(shù)不應(yīng)該包含敏感的客戶端或資源所有者的純文本信息，因?yàn)樗鼈兛赡茉诓话踩耐ǖ郎媳粋鬏敾虮徊话踩卮鎯?chǔ)。
10.9. 確保端點(diǎn)真實(shí)性
為了防止中間人攻擊，授權(quán)服務(wù)器必須對(duì)任何被發(fā)送到授權(quán)和令牌端點(diǎn)的請(qǐng)求要求RFC2818中定義的具有服務(wù)器身份驗(yàn)證的TLS 的使用?？蛻舳吮仨毎?a title="Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)" href="http://tools./html/rfc6125">RFC6125定義且按照它服務(wù)器身份進(jìn)行身份驗(yàn)證的需求驗(yàn)證授權(quán)服務(wù)器的的TLS證書。
10.10. 憑據(jù)猜測攻擊
授權(quán)服務(wù)器必須防止攻擊者猜測訪問令牌、授權(quán)碼、刷新令牌、資源所有者密碼和客戶端憑據(jù)。
攻擊者猜測已生成令牌（和其它不打算被最終用戶掌握的憑據(jù)）的概率必須小于或等于2 ^（-128），并且應(yīng)該小于或等于2 ^（-160）。
授權(quán)服務(wù)器必須采用其他手段來保護(hù)打算給最終用戶使用的憑據(jù)。
10.11. 釣魚攻擊
本協(xié)議或類似協(xié)議的廣泛部署，可能導(dǎo)致最終用戶變成習(xí)慣于被重定向到要求輸入他們的密碼的網(wǎng)站的做法。
如果最終用戶在輸入他們的憑據(jù)前不注意辨別這些網(wǎng)站的真?zhèn)?，這將使攻擊者利用這種做法竊取資源所有者的密碼成為可能。
服務(wù)提供者應(yīng)嘗試教育最終用戶有關(guān)釣魚攻擊構(gòu)成的風(fēng)險(xiǎn)，并且應(yīng)該為最終用戶提供使確認(rèn)它們的站點(diǎn)的真?zhèn)巫兊煤唵蔚臋C(jī)制?？蛻舳碎_發(fā)者應(yīng)該考慮他們?nèi)绾闻c用戶代理（例如，外部的和嵌入式的）交互的安全啟示以及最終用戶辨別授權(quán)服務(wù)器真?zhèn)蔚哪芰Α?/p>
為了減小釣魚攻擊的風(fēng)險(xiǎn)，授權(quán)服務(wù)器必須要求在用于最終用戶交互的每個(gè)端點(diǎn)上使用TLS。
10.12. 跨站請(qǐng)求偽造
跨站請(qǐng)求偽造（CSRF）是一種漏洞利用，攻擊者致使受害的最終用戶按惡意URI（例如以誤導(dǎo)的鏈接、圖片或重定向提供給用戶代理）到達(dá)受信任的服務(wù)器（通常由存在有效的會(huì)話Cookie而建立）。
針對(duì)客戶端的重定向URI的CSRF攻擊允許攻擊者注入自己的授權(quán)碼或訪問令牌，這將導(dǎo)致在客戶端中使用與攻擊者的受保護(hù)資源關(guān)聯(lián)的訪問令牌而非受害者的（例如，保存受害者的銀行賬戶信息到攻擊者控制的受保護(hù)資源）。
客戶端必須為它的重定向URI實(shí)現(xiàn)CSRF保護(hù)。這通常通過要求向重定向URI端點(diǎn)發(fā)送的任何請(qǐng)求包含該請(qǐng)求對(duì)用戶代理身份認(rèn)證狀態(tài)的綁定值（例如，用于對(duì)用戶代理進(jìn)行身份驗(yàn)證的會(huì)話Cookie的哈希值）來實(shí)現(xiàn)?？蛻舳藨?yīng)該使用“state”請(qǐng)求參數(shù)在發(fā)起授權(quán)請(qǐng)求時(shí)向授權(quán)服務(wù)器傳送該值。
一旦從最終用戶獲得授權(quán)，授權(quán)服務(wù)器重定向最終用戶的用戶代理帶著要求的包含在“state”參數(shù)中的綁定值回到客戶端。 通過該綁定值與用戶代理的身份驗(yàn)證狀態(tài)的匹配，綁定值使客戶端能夠驗(yàn)證請(qǐng)求的有效性。用于CSRF保護(hù)的綁定值必須包含不可猜測的值（如10.10節(jié)所述）且用戶代理的身份驗(yàn)證狀態(tài)（例如會(huì)話Cookie、HTML5本地存儲(chǔ)）必須保存在只能被客戶端和用戶代理訪問的地方（即通過同源策略保護(hù)）。
針對(duì)授權(quán)服務(wù)器的授權(quán)端點(diǎn)的CSRF攻擊可能導(dǎo)致攻擊者獲得最終用戶為惡意客戶端的授權(quán)而不牽涉或警告最終用戶。
授權(quán)服務(wù)器必須為它的授權(quán)端點(diǎn)實(shí)現(xiàn)CSRF保護(hù)并且確保在資源所有者未意識(shí)到且無顯式同意時(shí)惡意客戶端不能獲得授權(quán)。
10.13. 點(diǎn)擊劫持
在點(diǎn)擊劫持攻擊中，攻擊者注冊(cè)一個(gè)合法客戶端然后構(gòu)造一個(gè)惡意站點(diǎn)，在一個(gè)透明的覆蓋在一組虛假按鈕上面的嵌入框架中加載授權(quán)服務(wù)器的授權(quán)端點(diǎn)Web頁面，這些按鈕被精心構(gòu)造恰好放置在授權(quán)頁面上的重要按鈕下方。當(dāng)最終用戶點(diǎn)擊了一個(gè)誤導(dǎo)的可見的按鈕時(shí)，最終用戶實(shí)際上點(diǎn)擊了授權(quán)頁面上一個(gè)不可見的按鈕（例如“授權(quán)”按鈕）。 這允許攻擊者欺騙資源所有者許可它的客戶端最終用戶不知曉的訪問權(quán)限。
為了防止這種形式的攻擊，在請(qǐng)求最終用戶授權(quán)時(shí)本機(jī)應(yīng)用程序應(yīng)該使用外部瀏覽器而非應(yīng)用程序中嵌入的瀏覽器。 對(duì)于大多數(shù)較新的瀏覽器，避免嵌入框架可以由授權(quán)服務(wù)器使用（非標(biāo)準(zhǔn)的）“x-frame-options”標(biāo)頭實(shí)施。 該標(biāo)頭可以有兩個(gè)值，“deny”和“sameorigin”，它將阻止任何框架，或按不同來源的站點(diǎn)分別構(gòu)造框架。 對(duì)于較舊的瀏覽器，JavaScript框架破壞技術(shù)可以使用，但可能不會(huì)在所有的瀏覽器中生效。
10.14. 代碼注入和輸入驗(yàn)證
代碼注入攻擊當(dāng)程序使用的輸入或其他外部變量未清洗而導(dǎo)致對(duì)程序邏輯的修改時(shí)發(fā)生。 這可能允許攻擊者對(duì)應(yīng)用程序的設(shè)備或它的數(shù)據(jù)的訪問權(quán)限，導(dǎo)致服務(wù)拒絕或引入許多的惡意副作用。
授權(quán)服務(wù)器和客戶端必須清洗（并在可能的情況下驗(yàn)證）收到的任何值--特別是，“state”和“redirect_uri”參數(shù)的值。
10.15. 自由重定向器
授權(quán)服務(wù)器、授權(quán)端點(diǎn)和客戶端重定向端點(diǎn)可能被不當(dāng)配置，被作為自由重定向器。自由重定向器是一個(gè)使用參數(shù)自動(dòng)地向參數(shù)值指定而無任何驗(yàn)證的地址重定向用戶代理的端點(diǎn)。
自由重定向器可被用于釣魚攻擊，或者被攻擊者通過使用熟悉的受信任的目標(biāo)地址的URI授權(quán)部分使最終用戶訪問惡意站點(diǎn)。此外，如果授權(quán)服務(wù)器允許客戶端只注冊(cè)部分的重定向URI，攻擊者可以使用客戶端操作的自由重定向器構(gòu)造重定向URI，這將跳過授權(quán)服務(wù)器驗(yàn)證但是發(fā)送授權(quán)碼或訪問令牌給攻擊者控制下的端點(diǎn)。
10.16. 在隱式流程中濫用訪問令牌假冒資源所有者
對(duì)于使用隱式流程的公共客戶端，本規(guī)范沒有為客戶端提供任何方法來決定訪問令牌頒發(fā)給的是什么樣的客戶端。
資源所有者可能通過給攻擊者的惡意客戶端許可訪問令牌自愿委托資源的訪問權(quán)限。這可能是由于釣魚或一些其他借口。攻擊者也可能通過其他機(jī)制竊取令牌。 攻擊者然后可能會(huì)嘗試通過向合法公開客戶端提供該訪問令牌假冒資源擁有者。
在隱式流程（response_type=token）中，攻擊者可以輕易轉(zhuǎn)換來自授權(quán)服務(wù)器的響應(yīng)中的令牌，用事先頒發(fā)給攻擊者的令牌替換真實(shí)的訪問令牌。
依賴于在返回通道中傳遞訪問令牌識(shí)別客戶端用戶的與本機(jī)應(yīng)用程序通信的服務(wù)器可能由攻擊者創(chuàng)建能夠注入隨意的竊取的訪問令牌的危險(xiǎn)的程序被類似地危及。
任何做出只有資源所有者能夠提交給它有效的為資源的訪問令牌的假設(shè)的公共客戶端都是易受這種類型的攻擊的。
這種類型的攻擊可能在合法的客戶端上泄露有關(guān)資源所有者的信息給攻擊者（惡意客戶端）。這也將允許攻擊者在合法客戶端上用和資源所有者相同的權(quán)限執(zhí)行操作，該資源所有者最初許可了訪問令牌或授權(quán)碼。
客戶端對(duì)資源擁有者進(jìn)行身份驗(yàn)證超出了本規(guī)范的范圍。任何使用授權(quán)過程作為客戶端對(duì)受委托的最終用戶進(jìn)行身份驗(yàn)證的形式的規(guī)范（例如，第三方登錄服務(wù)）不能在沒有其他的客戶端能夠判斷訪問令牌是否頒發(fā)是頒發(fā)給它使用的安全機(jī)制的情況下使用隱式流程（例如，限制訪問令牌的受眾）。
11. IANA考量
在oauth-ext-review@郵件列表上的兩周的審查期后，根據(jù)一位或多位指定的專家的建議下，按規(guī)范需求（RFC5226）注冊(cè)訪問令牌類型。然而，為允許發(fā)表之前的值的分配，指定的專家（們）一旦他們對(duì)這樣的規(guī)范即將發(fā)布感到滿意可以同意注冊(cè)。
注冊(cè)請(qǐng)求必須使用正確的主題（例如“訪問令牌類型example”的請(qǐng)求）發(fā)送到oauth-ext-review@郵件列表來審查和評(píng)論。
在審查期間，指定的專家（們）將同意或拒絕該注冊(cè)請(qǐng)求，向?qū)彶榱斜砗虸ANA通報(bào)該決定。拒絕應(yīng)該包含解釋，并且可能的話，包含如何使請(qǐng)求成功的建議。
IANA必須只接受來自指定的專家（們）的注冊(cè)表更新并且應(yīng)該引導(dǎo)所有注冊(cè)請(qǐng)求至審查郵件列表。
11.1.1. 注冊(cè)模板
-
Type name：
請(qǐng)求的名稱（例如，“example”）。
-
Additional Token Endpoint Response Parameters:
隨“access_token”參數(shù)一起返回的其他響應(yīng)參數(shù)。 新的參數(shù)都必須如11.2節(jié)所述在OAuth參數(shù)注冊(cè)表中分別注冊(cè)。
-
HTTP Authentication Scheme(s):
HTTP身份驗(yàn)證方案名稱，如果有的話，用于使用這種類型的訪問令牌對(duì)受保護(hù)資源進(jìn)行身份驗(yàn)證。
-
Change controller：
對(duì)于標(biāo)準(zhǔn)化過程的RFC，指定為“IETF”。 對(duì)于其他，給出負(fù)責(zé)的部分的名稱。 其他細(xì)節(jié)（例如，郵政地址，電子郵件地址，主頁URI）也可以包括在內(nèi)。
-
Specification document(s):
指定參數(shù)的文檔的引用文獻(xiàn)，最好包括可以用于檢索文檔副本的URI。 相關(guān)章節(jié)的指示也可以包含但不是必需的。
11.2. OAuth參數(shù)注冊(cè)表
本規(guī)范建立OAuth參數(shù)注冊(cè)表。
在oauth-ext-review@郵件列表上的兩周的審查期后，根據(jù)一位或多位指定的專家的建議下，按規(guī)范需求（RFC5226）注冊(cè)列入授權(quán)端點(diǎn)請(qǐng)求、授權(quán)端點(diǎn)響應(yīng)、令牌端點(diǎn)請(qǐng)求或令牌端點(diǎn)響應(yīng)的其他參數(shù)。然而，為允許發(fā)表之前的值的分配，指定的專家（們）一旦他們對(duì)這樣的規(guī)范即將發(fā)布感到滿意可以同意注冊(cè)。
注冊(cè)請(qǐng)求必須使用正確的主題（例如，參數(shù)“example”的請(qǐng)求）發(fā)送到oauth-ext-review@郵件列表來審查和評(píng)論。
在審查期間，指定的專家（們）將同意或拒絕該注冊(cè)請(qǐng)求，向?qū)彶榱斜砗虸ANA通報(bào)該決定。拒絕應(yīng)該包含解釋，并且可能的話，包含如何使請(qǐng)求成功的建議。
IANA必須只接受來自指定的專家（們）的注冊(cè)表更新并且應(yīng)該引導(dǎo)所有注冊(cè)請(qǐng)求至審查郵件列表。
11.2.1. 注冊(cè)模板
-
Parameter name:
請(qǐng)求的名稱（例如，“example”）。
-
Parameter usage location:
參數(shù)可以使用的位置。 可能的位置為授權(quán)請(qǐng)求、授權(quán)響應(yīng)、令牌請(qǐng)求或令牌響應(yīng)。
-
Change controller:
對(duì)于標(biāo)準(zhǔn)化過程的RFC，指定為“IETF”。對(duì)于其他，給出負(fù)責(zé)的部分的名稱。其他細(xì)節(jié)（例如，郵政地址，電子郵件地址，主頁URI）也可以包括在內(nèi)。
-
Specification document(s):
指定參數(shù)的文檔的引用文獻(xiàn)，最好包括可以用于檢索文檔副本的URI。相關(guān)章節(jié)的指示也可以包含但不是必需的。
11.2.2. 最初的注冊(cè)表內(nèi)容
OAuth參數(shù)注冊(cè)表中的初始內(nèi)容：
- Parameter name: client_id
- Parameter usage location: authorization request, token request
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: client_secret
- Parameter usage location: token request
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: response_type
- Parameter usage location: authorization request
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: redirect_uri
- Parameter usage location: authorization request, token request
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: scope
- Parameter usage location: authorization request, authorization response, token request, token response
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: state
- Parameter usage location: authorization request, authorization response
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: code
- Parameter usage location: authorization response, token request
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: error_description
- Parameter usage location: authorization response, token response
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: error_uri
- Parameter usage location: authorization response, token response
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: grant_type
- Parameter usage location: token request
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: access_token
- Parameter usage location: authorization response, token response
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: token_type
- Parameter usage location: authorization response, token response
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: expires_in
- Parameter usage location: authorization response, token response
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: username
- Parameter usage location: token request
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: password
- Parameter usage location: token request
- Change controller: IETF
- Specification document(s):RFC 6749
- Parameter name: refresh_token
- Parameter usage location: token request, token response
- Change controller: IETF
- Specification document(s):RFC 6749
11.3. OAuth授權(quán)端點(diǎn)響應(yīng)類型注冊(cè)表
本規(guī)范建立OAuth授權(quán)端點(diǎn)響應(yīng)類型注冊(cè)表。
在oauth-ext-review@郵件列表上的兩周的審查期后，根據(jù)一位或多位指定的專家的建議下，按規(guī)范需求（RFC5226）注冊(cè)授權(quán)端點(diǎn)使用的其他響應(yīng)類型。然而，為允許發(fā)表之前的值的分配，指定的專家（們）一旦他們對(duì)這樣的規(guī)范即將發(fā)布感到滿意可以同意注冊(cè)。
注冊(cè)請(qǐng)求必須使用正確的主題（例如“響應(yīng)類型example”的請(qǐng)求）發(fā)送到oauth-ext-review@郵件列表來審查和評(píng)論。
在審查期間，指定的專家（們）將同意或拒絕該注冊(cè)請(qǐng)求，向?qū)彶榱斜砗虸ANA通報(bào)該決定。
IANA必須只接受來自指定的專家（們）的注冊(cè)表更新并且應(yīng)該引導(dǎo)所有注冊(cè)請(qǐng)求至審查郵件列表。
11.3.1. 注冊(cè)模板
-
Response type name:
請(qǐng)求的名稱（例如，“example”）。
-
Change controller:
對(duì)于標(biāo)準(zhǔn)化過程的RFC，指定為“IETF”。對(duì)于其他，給出負(fù)責(zé)的部分的名稱。其他細(xì)節(jié)（例如，郵政地址，電子郵件地址，主頁URI）也可以包括在內(nèi)。
-
Specification document(s):
指定參數(shù)的文檔的引用文獻(xiàn)，最好包括可以用于檢索文檔副本的URI。相關(guān)章節(jié)的指示也可以包含但不是必需的
11.3.2. 最初的注冊(cè)表內(nèi)容
OAuth授權(quán)端點(diǎn)響應(yīng)類型注冊(cè)表的初始內(nèi)容：
- Response type name: code
- Change controller: IETF
- Specification document(s):RFC 6749
- Response type name: token
- Change controller: IETF
- Specification document(s):RFC 6749
11.4. OAuth擴(kuò)展錯(cuò)誤注冊(cè)表
本規(guī)范建立OAuth擴(kuò)展錯(cuò)誤注冊(cè)表。
在oauth-ext-review@郵件列表上的兩周的審查期后，根據(jù)一位或多位指定的專家的建議下，按規(guī)范需求（RFC5226）注冊(cè)與其他協(xié)議擴(kuò)展（例如，擴(kuò)展的許可類型、訪問令牌類型或者擴(kuò)展參數(shù)）一起使用的其他錯(cuò)誤代碼。然而，為允許發(fā)表之前的值的分配，指定的專家（們）一旦他們對(duì)這樣的規(guī)范即將發(fā)布感到滿意可以同意注冊(cè)。
注冊(cè)請(qǐng)求必須使用正確的主題（例如“錯(cuò)誤代碼example”的請(qǐng)求）發(fā)送到oauth-ext-review@郵件列表來審查和評(píng)論。
在審查期間，指定的專家（們）將同意或拒絕該注冊(cè)請(qǐng)求，向?qū)彶榱斜砗虸ANA通報(bào)該決定。拒絕應(yīng)該包含解釋，并且可能的話，包含如何使請(qǐng)求成功的建議。
IANA必須只接受來自指定的專家（們）的注冊(cè)表更新并且應(yīng)該引導(dǎo)所有注冊(cè)請(qǐng)求至審查郵件列表。
11.4.1. 注冊(cè)模板
-
Error name:
請(qǐng)求的名稱（例如，“example”）。錯(cuò)誤名稱的值
不能包含集合%x20-21 /%x23-5B /%x5D-7E以外的字符。
-
Error usage location:
錯(cuò)誤使用的位置。可能的位置是授權(quán)代碼許可錯(cuò)誤響應(yīng)（4.1.2.1節(jié)），隱式許可錯(cuò)誤響應(yīng)（4.2.2.1節(jié)），令牌錯(cuò)誤響應(yīng)（5.2節(jié)），或資源訪問錯(cuò)誤的響應(yīng)（7.2節(jié)）。
-
Related protocol extension:
與錯(cuò)語代碼一起使用的擴(kuò)展許可類型、訪問令牌類型或擴(kuò)展參數(shù)的名稱。
-
Change controller:
對(duì)于標(biāo)準(zhǔn)化過程的RFC，指定為“IETF”。對(duì)于其他，給出負(fù)責(zé)的部分的名稱。其他細(xì)節(jié)（例如，郵政地址，電子郵件地址，主頁URI）也可以包括在內(nèi)。
-
Specification document(s):
指定參數(shù)的文檔的引用文獻(xiàn)，最好包括可以用于檢索文檔副本的URI。相關(guān)章節(jié)的指示也可以包含但不是必需的。
