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