RESTful API架構和oauth2.0認證機制（概念版）

REST全稱是Representational State Transfer，中文意思是表述（編者注：通常譯為表征）性狀態轉移。它首次出現在2000年Roy Fielding的博士論文中，Roy Fielding是HTTP規范的主要編寫者之一。他在論文中提到："我這篇文章的寫作目的，就是想在符合架構原理的前提下，理解和評估以網絡為基礎的應用軟件的架構設計，得到一個功能強、性能好、適宜通信的架構。REST指的是一組架構約束條件和原則。" 如果一個架構符合REST的約束條件和原則，我們就稱它為RESTful架構。

REST本身並沒有創造新的技術、組件或服務，而隱藏在RESTful背后的理念就是使用Web的現有特征和能力，更好地使用現有Web標准中的一些准則和約束。雖然REST本身受Web技術的影響很深，但是理論上REST架構風格並不是綁定在HTTP上，只不過目前HTTP是唯一與REST相關的實例。所以我們這里描述的REST也是通過HTTP實現的REST。

2. 理解RESTful

要理解RESTful架構，需要理解Representational State Transfer這個詞組到底是什么意思，它的每一個詞都有些什么涵義。

下面我們結合REST原則，圍繞資源展開討論，從資源的定義、獲取、表述、關聯、狀態變遷等角度，列舉一些關鍵概念並加以解釋。

資源與URI
統一資源接口
資源的表述
資源的鏈接
狀態的轉移

2. 1 資源與URI

REST全稱是表述性狀態轉移，那究竟指的是什么的表述? 其實指的就是資源。任何事物，只要有被引用到的必要，它就是一個資源。資源可以是實體(例如手機號碼)，也可以只是一個抽象概念(例如價值) 。下面是一些資源的例子：

某用戶的手機號碼
某用戶的個人信息
最多用戶訂購的GPRS套餐
兩個產品之間的依賴關系
某用戶可以辦理的優惠套餐
某手機號碼的潛在價值

要讓一個資源可以被識別，需要有個唯一標識，在Web中這個唯一標識就是URI(Uniform Resource Identifier)。

URI既可以看成是資源的地址，也可以看成是資源的名稱。如果某些信息沒有使用URI來表示，那它就不能算是一個資源，只能算是資源的一些信息而已。URI的設計應該遵循可尋址性原則，具有自描述性，需要在形式上給人以直覺上的關聯。這里以github網站為例，給出一些還算不錯的URI：

https://github.com/git
https://github.com/git/git
https://github.com/git/git/blob/master/block-sha1/sha1.h
https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08
https://github.com/git/git/pulls
https://github.com/git/git/pulls?state=closed
https://github.com/git/git/compare/master…next

下面讓我們來看看URI設計上的一些技巧:

使用_或-來讓URI可讀性更好

曾經Web上的URI都是冰冷的數字或者無意義的字符串，但現在越來越多的網站使用_或-來分隔一些單詞，讓URI看上去更為人性化。例如國內比較出名的開源中國社區，它上面的新聞地址就采用這種風格，如http://www.oschina.net/news/38119/oschina-translate-reward-plan。

使用/來表示資源的層級關系

例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08就表示了一個多級的資源，指的是git用戶的git項目的某次提交記錄，又例如/orders/2012/10可以用來表示2012年10月的訂單記錄。

使用?用來過濾資源

很多人只是把?簡單的當做是參數的傳遞，很容易造成URI過於復雜、難以理解。可以把?用於對資源的過濾，例如/git/git/pulls用來表示git項目的所有推入請求，而/pulls?state=closed用來表示git項目中已經關閉的推入請求，這種URL通常對應的是一些特定條件的查詢結果或算法運算結果。

,或;可以用來表示同級資源的關系

有時候我們需要表示同級資源的關系時，可以使用,或;來進行分割。例如哪天github可以比較某個文件在隨意兩次提交記錄之間的差異，或許可以使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca作為URI。不過，現在github是使用…來做這個事情的，例如/git/git/compare/master…next。

2. 2 統一資源接口

RESTful架構應該遵循統一接口原則，統一接口包含了一組受限的預定義的操作，不論什么樣的資源，都是通過使用相同的接口進行資源的訪問。接口應該使用標准的HTTP方法如GET，PUT和POST，並遵循這些方法的語義。

如果按照HTTP方法的語義來暴露資源，那么接口將會擁有安全性和冪等性的特性，例如GET和HEAD請求都是安全的，無論請求多少次，都不會改變服務器狀態。而GET、HEAD、PUT和DELETE請求都是冪等的，無論對資源操作多少次，結果總是一樣的，后面的請求並不會產生比第一次更多的影響。

下面列出了GET，DELETE，PUT和POST的典型用法:

GET

安全且冪等
獲取表示
變更時獲取表示（緩存）

200（OK） - 表示已在響應中發出

204（無內容） - 資源有空表示
301（Moved Permanently） - 資源的URI已被更新
303（See Other） - 其他（如，負載均衡）
304（not modified）- 資源未更改（緩存）
400 （bad request）- 指代壞請求（如，參數錯誤）
404 （not found）- 資源不存在
406 （not acceptable）- 服務端不支持所需表示
500 （internal server error）- 通用錯誤響應
503 （Service Unavailable）- 服務端當前無法處理請求

POST

不安全且不冪等
使用服務端管理的（自動產生）的實例號創建資源
創建子資源
部分更新資源
如果沒有被修改，則不過更新資源（樂觀鎖）

200（OK）- 如果現有資源已被更改

201（created）- 如果新資源被創建
202（accepted）- 已接受處理請求但尚未完成（異步處理）
301（Moved Permanently）- 資源的URI被更新
303（See Other）- 其他（如，負載均衡）
400（bad request）- 指代壞請求
404 （not found）- 資源不存在
406 （not acceptable）- 服務端不支持所需表示
409 （conflict）- 通用沖突
412 （Precondition Failed）- 前置條件失敗（如執行條件更新時的沖突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用錯誤響應
503 （Service Unavailable）- 服務當前無法處理請求

PUT

不安全但冪等
用客戶端管理的實例號創建一個資源
通過替換的方式更新資源
如果未被修改，則更新資源（樂觀鎖）

200 （OK）- 如果已存在資源被更改

201 （created）- 如果新資源被創建
301（Moved Permanently）- 資源的URI已更改
303 （See Other）- 其他（如，負載均衡）
400 （bad request）- 指代壞請求
404 （not found）- 資源不存在
406 （not acceptable）- 服務端不支持所需表示
409 （conflict）- 通用沖突
412 （Precondition Failed）- 前置條件失敗（如執行條件更新時的沖突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用錯誤響應
503 （Service Unavailable）- 服務當前無法處理請求

DELETE

不安全但冪等
刪除資源

200 （OK）- 資源已被刪除

301 （Moved Permanently）- 資源的URI已更改
303 （See Other）- 其他，如負載均衡
400 （bad request）- 指代壞請求
404 （not found）- 資源不存在
409 （conflict）- 通用沖突
500 （internal server error）- 通用錯誤響應
503 （Service Unavailable）- 服務端當前無法處理請求

下面我們來看一些實踐中常見的問題:

POST和PUT用於創建資源時有什么區別?

POST和PUT在創建資源的區別在於，所創建的資源的名稱(URI)是否由客戶端決定。例如為我的博文增加一個java的分類，生成的路徑就是分類名/categories/java，那么就可以采用PUT方法。不過很多人直接把POST、GET、PUT、DELETE直接對應上CRUD，例如在一個典型的rails實現的RESTful應用中就是這么做的。

我認為，這是因為rails默認使用服務端生成的ID作為URI的緣故，而不少人就是通過rails實踐REST的，所以很容易造成這種誤解。

客戶端不一定都支持這些HTTP方法吧?

的確有這種情況，特別是一些比較古老的基於瀏覽器的客戶端，只能支持GET和POST兩種方法。

在實踐上，客戶端和服務端都可能需要做一些妥協。例如rails框架就支持通過隱藏參數_method=DELETE來傳遞真實的請求方法，而像Backbone這樣的客戶端MVC框架則允許傳遞_method傳輸和設置X-HTTP-Method-Override頭來規避這個問題。

統一接口是否意味着不能擴展帶特殊語義的方法?

統一接口並不阻止你擴展方法，只要方法對資源的操作有着具體的、可識別的語義即可，並能夠保持整個接口的統一性。

像WebDAV就對HTTP方法進行了擴展，增加了LOCK、UPLOCK等方法。而github的API則支持使用PATCH方法來進行issue的更新，例如:

PATCH /repos/:owner/:repo/issues/:number

不過，需要注意的是，像PATCH這種不是HTTP標准方法的，服務端需要考慮客戶端是否能夠支持的問題。

統一資源接口對URI有什么指導意義?

統一資源接口要求使用標准的HTTP方法對資源進行操作，所以URI只應該來表示資源的名稱，而不應該包括資源的操作。

通俗來說，URI不應該使用動作來描述。例如，下面是一些不符合統一接口要求的URI:

GET /getUser/1
POST /createUser
PUT /updateUser/1
DELETE /deleteUser/1

如果GET請求增加計數器，這是否違反安全性?

安全性不代表請求不產生副作用，例如像很多API開發平台，都對請求流量做限制。像github，就會限制沒有認證的請求每小時只能請求60次。

但客戶端不是為了追求副作用而發出這些GET或HEAD請求的，產生副作用是服務端"自作主張"的。

另外，服務端在設計時，也不應該讓副作用太大，因為客戶端認為這些請求是不會產生副作用的。

直接忽視緩存可取嗎?

即使你按各個動詞的原本意圖來使用它們，你仍可以輕易禁止緩存機制。最簡單的做法就是在你的HTTP響應里增加這樣一個報頭： Cache-control: no-cache。但是，同時你也對失去了高效的緩存與再驗證的支持(使用Etag等機制)。

對於客戶端來說，在為一個REST式服務實現程序客戶端時，也應該充分利用現有的緩存機制，以免每次都重新獲取表示。

響應代碼的處理有必要嗎?

HTTP的響應代碼可用於應付不同場合，正確使用這些狀態代碼意味着客戶端與服務器可以在一個具備較豐富語義的層次上進行溝通。

例如，201（"Created"）響應代碼表明已經創建了一個新的資源，其URI在Location響應報頭里。

假如你不利用HTTP狀態代碼豐富的應用語義，那么你將錯失提高重用性、增強互操作性和提升松耦合性的機會。

如果這些所謂的RESTful應用必須通過響應實體才能給出錯誤信息，那么SOAP就是這樣的了，它就能夠滿足了。

2. 3 資源的表述

上面提到，客戶端通過HTTP方法可以獲取資源，是吧? 不，確切的說，客戶端獲取的只是資源的表述而已。資源在外界的具體呈現，可以有多種表述(或成為表現、表示)形式，在客戶端和服務端之間傳送的也是資源的表述，而不是資源本身。例如文本資源可以采用html、xml、json等格式，圖片可以使用PNG或JPG展現出來。

資源的表述包括數據和描述數據的元數據，例如，HTTP頭"Content-Type" 就是這樣一個元數據屬性。

那么客戶端如何知道服務端提供哪種表述形式呢?

答案是可以通過HTTP內容協商，客戶端可以通過Accept頭請求一種特定格式的表述，服務端則通過Content-Type告訴客戶端資源的表述形式。

以github為例，請求某組織資源的json格式的表述形式:

291731048886033

　假如github也能夠支持xml格式的表述格式，那么結果就是這樣的:

291731045756062

　下面我們來看一些實踐上常見的設計:

在URI里邊帶上版本號

有些API在URI里邊帶上版本號，例如:

http://api.example.com/1.0/foo
http://api.example.com/1.2/foo
http://api.example.com/2.0/foo

如果我們把版本號理解成資源的不同表述形式的話，就應該只是用一個URL，並通過Accept頭部來區分，還是以github為例，它的Accept的完整格式是:application/vnd.github[.version].param[+json]

對於v3版本的話，就是Accept: application/vnd.github.v3。對於上面的例子，同理可以使用使用下面的頭部:

Accept: vnd.example-com.foo+json; version=1.0
Accept: vnd.example-com.foo+json; version=1.2
Accept: vnd.example-com.foo+json; version=2.0

使用URI后綴來區分表述格式

像rails框架，就支持使用/users.xml或/users.json來區分不同的格式。這樣的方式對於客戶端來說，無疑是更為直觀，但混淆了資源的名稱和資源的表述形式。我個人認為，還是應該優先使用內容協商來區分表述格式。

如何處理不支持的表述格式

當服務器不支持所請求的表述格式，那么應該怎么辦？若服務器不支持，它應該返回一個HTTP 406響應，表示拒絕處理該請求。下面以github為例，展示了一個請求XML表述資源的結果：

291732082474844

2. 4 資源的鏈接

我們知道REST是使用標准的HTTP方法來操作資源的，但僅僅因此就理解成帶CURD的Web數據庫架構就太過於簡單了。

這種反模式忽略了一個核心概念："超媒體即應用狀態引擎（hypermedia as the engine of application state）"。超媒體是什么?

當你瀏覽Web網頁時，從一個連接跳到一個頁面，再從另一個連接跳到另外一個頁面，就是利用了超媒體的概念：把一個個把資源鏈接起來.

要達到這個目的，就要求在表述格式里邊加入鏈接來引導客戶端。在《RESTful Web Services》一書中，作者把這種具有鏈接的特性成為連通性。下面我們具體來看一些例子。

下面展示的是github獲取某個組織下的項目列表的請求，可以看到在響應頭里邊增加Link頭告訴客戶端怎么訪問下一頁和最后一頁的記錄。而在響應體里邊，用url來鏈接項目所有者和項目地址。

291731042784620

　　又例如下面這個例子，創建訂單后通過鏈接引導客戶端如何去付款。

上面的例子展示了如何使用超媒體來增強資源的連通性。很多人在設計RESTful架構時，使用很多時間來尋找漂亮的URI，而忽略了超媒體。所以，應該多花一些時間來給資源的表述提供鏈接，而不是專注於"資源的CRUD"。

2. 5 狀態的轉移

有了上面的鋪墊，再討論REST里邊的狀態轉移就會很容易理解了。

不過，我們先來討論一下REST原則中的無狀態通信原則。初看一下，好像自相矛盾了，既然無狀態，何來狀態轉移一說?

其實，這里說的無狀態通信原則，並不是說客戶端應用不能有狀態，而是指服務端不應該保存客戶端狀態。

2. 5.1 應用狀態與資源狀態

實際上，狀態應該區分應用狀態和資源狀態，客戶端負責維護應用狀態，而服務端維護資源狀態。

客戶端與服務端的交互必須是無狀態的，並在每一次請求中包含處理該請求所需的一切信息。

服務端不需要在請求間保留應用狀態，只有在接受到實際請求的時候，服務端才會關注應用狀態。

這種無狀態通信原則，使得服務端和中介能夠理解獨立的請求和響應。

在多次請求中，同一客戶端也不再需要依賴於同一服務器，方便實現高可擴展和高可用性的服務端。

但有時候我們會做出違反無狀態通信原則的設計，例如利用Cookie跟蹤某個服務端會話狀態，常見的像J2EE里邊的JSESSIONID。

這意味着，瀏覽器隨各次請求發出去的Cookie是被用於構建會話狀態的。

當然，如果Cookie保存的是一些服務器不依賴於會話狀態即可驗證的信息（比如認證令牌），這樣的Cookie也是符合REST原則的。

2. 5.2 應用狀態的轉移

狀態轉移到這里已經很好理解了， "會話"狀態不是作為資源狀態保存在服務端的，而是被客戶端作為應用狀態進行跟蹤的。客戶端應用狀態在服務端提供的超媒體的指引下發生變遷。服務端通過超媒體告訴客戶端當前狀態有哪些后續狀態可以進入。

這些類似"下一頁"之類的鏈接起的就是這種推進狀態的作用——指引你如何從當前狀態進入下一個可能的狀態。

3. 總結

現在廣東XXX版本、XXX等項目中均使用傳統的RPC、SOAP方式的Web服務，而移動南方基地XXXX項目的后台，雖然采用了JSON格式進行交互，但還是屬於RPC風格的。本文從資源的定義、獲取、表述、關聯、狀態變遷等角度，試圖快速理解RESTful架構背后的概念。RESTful架構與傳統的RPC、SOAP等方式在理念上有很大的不同，希望本文能對各位理解REST有所幫助。

RESTfulAPI架構轉載於 http://www.runoob.com/w3cnote/restful-architecture.html

三、什么是oauth2.0協議標准?


   在傳統的客戶端 - 服務器認證模型中，客戶端
   請求訪問受限資源（受保護資源）
   服務器通過使用資源所有者的服務器進行身份驗證
   證書。為了提供第三方應用程序訪問權限
   受限資源，資源所有者與其共享憑證
   第三方。這造成了幾個問題和局限性：

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

   o盡管如此，服務器仍然需要支持密碼認證
      密碼固有的安全弱點。

   o第三方應用程序獲得對資源的過度廣泛訪問
      所有者的受保護資源，使資源所有者無任何責任
      限制持續時間或訪問有限子集的能力
      資源。

   o資源所有者不能撤銷對個人第三方的訪問權限
      而不會取消所有第三方的訪問權限，並且必須通過
      更改第三方的密碼。

 o妥協的任何第三方應用程序導致妥協 最終用戶的密碼以及所有受其保護的數據 密碼。 OAuth通過引入授權層來解決這些問題 並將客戶的角色與資源的角色分開 所有者。在OAuth中，客戶端請求訪問受控資源 由資源所有者和資源服務器托管，並且是 發布了不同於該資源的憑證 所有者。 而不是使用資源所有者的憑據來訪問受保護的 資源，客戶端獲得一個訪問令牌 - 一個表示一個字符串的字符串 特定范圍，生命周期和其他訪問屬性。訪問令牌 由授權服務器向第三方客戶發放 資源所有者的批准。客戶端使用訪問令牌 訪問由資源服務器托管的受保護資源。 例如，最終用戶（資源所有者）可以授予打印 服務（客戶端）訪問存儲在照片上的受保護照片， 共享服務（資源服務器），而不共享她的用戶名和密碼 密碼與打印服務。相反，她認證 直接與照片共享服務所信任的服務器直接相連 （授權服務器），它發布打印服務委托 - 特定憑證（訪問令牌）。 本規范旨在與HTTP（[ RFC2616 ]）一起使用。該 通過除HTTP以外的任何協議使用OAuth超出范圍。 OAuth 1.0協議（[ RFC5849 ]），作為信息發布 文件，是小型特別社區努力的結果。這個 Standards Track規范基於OAuth 1.0部署 經驗以及其他用例和可擴展性 從更廣泛的IETF社區收集要求。OAuth 2.0 協議不向后兼容OAuth 1.0。這兩個版本 可能在網絡上共存，並且實現可能選擇 支持兩者。但是，這是本規范的意圖 新的實現支持在此指定的OAuth 2.0 文檔，並且OAuth 1.0僅用於支持現有的 部署。OAuth 2.0協議共享的實現非常少 使用OAuth 1.0協議的詳細信息。熟悉的實施者 OAuth 1.0應該在不做任何假設的情況下處理本文檔 其結構和細節。

 OAuth定義了四個角色： 資源所有者 一個能夠授權訪問受保護資源的實體。 當資源所有者是一個人時，它被稱為一個人 最終用戶。 資源服務器 承載受保護資源的服務器，能夠接受 並使用訪問令牌響應受保護的資源請求。 客戶 一個應用程序代表 資源所有者和授權。術語“客戶”的確如此 並不意味着任何特定的實施特征（例如， 應用程序是否在服務器，桌面或其他應用程序上執行 設備）。 授權服務器 服務器成功后向客戶端發放訪問令牌 驗證資源所有者並獲得授權。 授權服務器和資源服務器之間的交互 超出了本規范的范圍。授權服務器 可以是與資源服務器相同的服務器或單獨的實體。 一個授權服務器可能會發出接受的訪問令牌 多個資源服務器。

 + -------- + + --------------- + | | - （A） - 授權請求 - > | 資源| | | | 所有者| | | < - （B） - 授權許可 - | | | | + --------------- + | | | | + --------------- + | | - （C） - 授權許可 - > | 授權| | 客戶端| | 服務器| | | < - （D）-----訪問令牌------- | | | | + --------------- + | | | | + --------------- + | | - （E）-----訪問令牌------> | 資源| | | | 服務器| | | < - （F）---受保護的資源--- | | + -------- + + --------------- + 圖1：抽象協議流程 圖1中所示的抽象OAuth 2.0流程描述了 四個角色之間的交互，並包括以下步驟： （A）客戶端請求來自資源所有者的授權。該 可以直接向資源所有者授權請求 （如圖所示），或者優選間接通過授權 服務器作為中介。 （B）客戶收到授權許可，這是一個 代表資源所有者授權的憑證， 用本文定義的四種授權類型之一表示 規范或使用擴展授權類型。該 授權授予類型取決於使用的方法 客戶端請求授權和類型支持的類型 授權服務器。 （C）客戶通過使用身份驗證來請求訪問令牌 授權服務器並提交授權許可。 （D）授權服務器驗證客戶端並驗證 授權許可，如果有效，則發出訪問令牌。

 （E）客戶端從資源請求受保護的資源 服務器並通過呈現訪問令牌進行身份驗證。 （F）資源服務器驗證訪問令牌，如果有效， 服務於請求。 客戶獲得授權許可的首選方法 來自資源所有者（在步驟（A）和（B）中描述）是使用 授權服務器作為中介，如圖所示第4.1節中的 圖3 。  授權許可是代表資源的憑證 所有者授權（訪問其受保護的資源） 客戶端來獲取訪問令牌。這個規范定義了四個 授予類型 - 授權碼，隱式，資源所有者密碼 憑據和客戶端憑據 - 以及可擴展性 定義附加類型的機制。  授權碼是使用授權服務器獲得的 作為客戶和資源所有者之間的中介。代替 直接從資源所有者，客戶端請求授權 將資源所有者引導至授權服務器（通過其授權服務器） 用戶代理，如[ RFC2616 ]中所定義的），這反過來指導着 資源所有者用授權碼返回給客戶端。 在將資源所有者重定向到客戶端之前 授權碼，授權服務器驗證 資源所有者並獲得授權。因為資源所有者 只與授權服務器，資源進行身份驗證 所有者的憑證永遠不會與客戶共享。 授權代碼提供了一些重要的安全優勢， 如驗證客戶端的能力，以及 無需將訪問令牌直接傳輸到客戶端 將其傳遞給資源所有者的用戶代理和潛在的用戶代理 將其展示給其他人，包括資源所有者。  隱式授權是優化的簡化授權碼流 對於使用腳本語言等在瀏覽器中實現的客戶端 作為JavaScript。在隱式流程中，而不是發布客戶端 一個授權碼，客戶端直接發出訪問令牌

 （作為資源所有者授權的結果）。授予類型 是隱含的，因為沒有中間憑據（例如授權 代碼）被發布（並且隨后用於獲得訪問令牌）。 在隱式授權流程期間發出訪問令牌時， 授權服務器不認證客戶端。在一些 情況下，客戶端身份可以通過重定向URI進行驗證 用於將訪問令牌傳遞給客戶端。訪問令牌可能 暴露給資源所有者或其他有權訪問的應用程序 資源所有者的用戶代理。 隱性贈款可以提高某些人的反應速度和效率 客戶端（例如作為瀏覽器內應用程序實現的客戶端）， 因為它減少了獲得一個所需的往返次數 訪問令牌。但是，這種便利應該權衡 使用隱含授權的安全影響，如那些 在10.3節和10.16節中介紹，特別是當 授權碼授權類型可用。 。 資源所有者密碼憑證（即用戶名和密碼） 可以直接用作授權許可來獲得訪問權限 令牌。這些憑據只能在高價時使用 資源所有者與客戶之間的信任度（例如， 客戶端是設備操作系統的一部分或高度特權 應用程序），以及其他授權授權類型不適用時 可用（例如授權碼）。 即使這種授予類型需要直接客戶端訪問 資源所有者憑證，則使用資源所有者憑證 對於單個請求並交換訪問令牌。這個 授予類型可以消除客戶端存儲的需要 資源所有者憑據以供將來使用，通過交換 具有長期訪問令牌或刷新令牌的憑證。 。 客戶端憑據（或其他形式的客戶端身份驗證）可以 作為授權范圍時的授權許可 限於受客戶控制的受保護資源， 或先前安排授權的受保護資源 服務器。客戶端憑證用作授權許可 通常當客戶以自己的名義行事時（客戶是 也是資源所有者）或正在請求訪問受保護的資源 資源基於先前安排的授權 授權服務器。

 訪問令牌是用於訪問受保護資源的憑證。一個 訪問令牌是一個字符串，表示授予該授權的授權 客戶。該字符串通常對客戶端不透明。令牌 代表訪問的具體范圍和持續時間，由授予 資源所有者，並由資源服務器和授權執行 服務器。 令牌可以表示用於檢索授權的標識符 信息或者可以自行包含授權信息 可驗證的方式（即由一些數據和a組成的標記字符串 簽名）。額外的認證證書，超越 本規范的范圍，可能需要為了 客戶端使用令牌。 訪問令牌提供了一個抽象層，取代了不同的層 授權構造（例如，用戶名和密碼）與單一 令牌可以被資源服務器理解。這種抽象使能 發放比授權授權更具限制性的訪問令牌 用於獲取它們，以及刪除資源服務器的需求 了解廣泛的認證方法。 訪問令牌可以具有不同的格式，結構和方法 基於資源的利用（例如，密碼特性） 服務器安全要求。訪問令牌屬性和 用於訪問受保護資源的方法超出了范圍 這個規范是由相關規范等定義的 作為[ RFC6750 ]。 。 刷新令牌是用於獲取訪問令牌的憑證。刷新 令牌是由授權服務器發給客戶端的 用於獲取當前訪問令牌的新訪問令牌 變為無效或到期，或獲得額外的訪問令牌 具有相同或更窄的范圍（訪問令牌可能更短 終身和更少的權限比資源授權 所有者）。發布刷新令牌是可選的，可以自行決定 授權服務器。如果授權服務器發出刷新 令牌，它包含在發出訪問令牌時（即步驟（D）） 圖1）。 刷新令牌是表示授予的授權的字符串 客戶端由資源所有者。該字符串通常是不透明的 客戶端。令牌表示用於檢索的標識符

 授權信息。與訪問令牌不同，刷新令牌是 打算只用於授權服務器，並且從不發送 到資源服務器。 + -------- + + --------------- + | | - （A）-------授權津貼---------> | | | | | | | | < - （B）-----------訪問令牌------------- | | | | 刷新令牌| | | | | | | | + ---------- + | | | | - （C）----訪問令牌----> | | | | | | | | | | | | < - （D） - 受保護的資源 - | 資源| | 授權| | 客戶端| | 服務器| | 服務器| | | - （E）----訪問令牌----> | | | | | | | | | | | | < - （F） - 令牌錯誤無效 - | | | | | | + ---------- + | | | | | | | | - （G）-----------刷新令牌-----------> | | | | | | | | < - （H）-----------訪問令牌------------- | | + -------- +＆可選刷新令牌+ --------------- + 圖2：刷新過期的訪問令牌 圖2所示的流程包括以下步驟： （A）客戶通過使用身份驗證來請求訪問令牌 授權服務器並提交授權許可。 （B）授權服務器認證客戶端並驗證 授權許可，如果有效，則發出訪問令牌 和一個刷新令牌。 （C）客戶端向資源發出受保護的資源請求 服務器通過提供訪問令牌。 （D）資源服務器驗證訪問令牌，如果有效， 服務於請求。 （E）重復步驟（C）和（D），直到訪問令牌到期。如果 客戶端知道訪問令牌已過期，跳到步驟（G）; 否則，它會發出另一個受保護資源請求。 （F）由於訪問令牌無效，資源服務器返回 無效的令牌錯誤。

 （G）客戶端通過身份驗證請求新的訪問令牌 授權服務器並呈現刷新令牌。該 客戶端身份驗證要求基於客戶端類型 和授權服務器策略。 （H）授權服務器認證客戶端並驗證 刷新令牌，如果有效，則發出新的訪問令牌（並且， 可選地，新的刷新令牌）。 步驟（C），（D），（E）和（F）不在此范圍內 規范，如第7節所述。 。 無論何時使用傳輸層安全性（TLS） 規范，TLS的適當版本（或多個版本）會有所不同 隨着時間的推移，基於廣泛的部署和已知的安全性 漏洞。在撰寫本文時，TLS版本1.2 [ RFC5246 ]是最新的版本，但有一個非常有限的 部署基地，並且可能不容易獲得 實現。TLS版本1.0 [ RFC2246 ]是最廣泛的 部署版本並將提供最廣泛的互操作性。 實現也可以支持額外的傳輸層安全 滿足其安全要求的機制。 。 該規范廣泛使用HTTP重定向，其中 客戶端或授權服務器指導資源所有者 用戶代理到另一個目的地。雖然在這個例子 規范顯示使用HTTP 302狀態碼，任何其他 方法可通過用戶代理完成此重定向 被允許並且被認為是實現細節。 。 OAuth 2.0提供了一個具有明確定義的豐富的授權框架 安全屬性。但是，作為一個富有和高度可擴展的 這個框架包含許多可選組件 規范很可能會產生大范圍的非互操作性 實現。 另外，這個規范留下了一些必需的組件 部分或完全未定義（例如，客戶注冊， 授權服務器功能，端點發現）。沒有

 這些組件，客戶端必須手動和專門 針對特定授權服務器和資源進行配置 服務器以便互操作。 這個框架的設計有着明確的未來 工作將定義必要的規定性配置文件和擴展 實現全面的網絡規模互操作性。 。 關鍵詞“必須”，“不得”，“需要”，“應該”，“不應該”， “應該”，“不應該”，“推薦”，“可能”和“可選” 規范應按 [ RFC2119 ]中的描述進行解釋。 本規范使用增強的Backus-Naur表單（ABNF） [ RFC5234 ]的符號。另外，規則URI引用是 從“統一資源標識符（URI）：通用語法” [ RFC3986 ]。 某些安全相關的術語在某種意義上應該被理解 在[ RFC4949 ]中定義。這些條款包括但不限於， “攻擊”，“認證”，“授權”，“證書”， “機密性”，“憑證”，“加密”，“身份”，“標志”， “簽名”，“信任”，“驗證”和“驗證”。 除非另有說明，否則所有協議參數名稱和值 區分大小寫。 。 在啟動協議之前，客戶端使用 授權服務器。客戶注冊的手段 與授權服務器不在此范圍之內 規范，但通常涉及最終用戶與HTML的交互 報名表格。 客戶注冊不需要直接互動 客戶端和授權服務器。當被支持的時候 授權服務器，注冊可以依靠其他手段進行 建立信任並獲得所需的客戶屬性 （例如，重定向URI，客戶端類型）。例如，注冊可以 通過自發或第三方發布的斷言來完成， 或者由授權服務器使用a執行客戶端發現 可信渠道。

 在注冊客戶端時，客戶端開發者應該： o按2.1節所述指定客戶端類型， o按3.1.2節所述提供其客戶端重定向URI ， 和 o包括授權服務器要求的任何其他信息 （例如，應用程序名稱，網站，說明，徽標圖像， 接受法律條款）。 。 OAuth根據他們的能力定義了兩種客戶端類型 使用授權服務器進行安全認證（例如， 保持其客戶證書的機密性）： 機密 有能力維護他們的隱私的客戶 憑證（例如，在安全服務器上實施的客戶端 對客戶端證書的訪問受限）或安全 客戶認證使用其他手段。 上市 無法維護其客戶機密的客戶 憑據（例如，在設備上使用的客戶端上執行的客戶端） 資源所有者，例如已安裝的本機應用程序或Web 基於瀏覽器的應用程序），並且不具備安全的客戶端 通過任何其他方式進行認證 客戶端類型指定基於授權服務器 安全認證的定義及其可接受的暴露 客戶端憑證級別。授權服務器不應該 對客戶類型做出假設。 客戶可以作為分布式組件來實現，每個組件都可以實現 與不同的客戶端類型和安全上下文（例如，a 分布式客戶端同時擁有一個基於服務器的機密組件 和一個基於瀏覽器的公共組件）。如果授權服務器 不為這些客戶提供支持或不提供 有關其注冊的指導，客戶應該 將每個組件注冊為單獨的客戶端。

 本規范是圍繞以下客戶設計的 簡介： Web應用程序 Web應用程序是在網絡上運行的機密客戶端 服務器。資源所有者通過HTML用戶訪問客戶端 界面呈現在用戶代理上使用的設備上 資源所有者。客戶端憑證以及任何訪問權限 發給客戶端的令牌存儲在Web服務器上並且是 沒有暴露給資源所有者或可被資源所有者訪問 基於用戶代理的應用程序 基於用戶代理的應用程序是一個公共客戶， 客戶端代碼從Web服務器下載並在一個 用戶代理（例如，網絡瀏覽器）在資源使用的設備上 所有者。協議數據和證書很容易訪問（和 經常可見）給資源所有者。自此類應用程序 駐留在用戶代理中，他們可以無縫地使用該用戶代理 用戶代理功能請求授權時。 原生應用程序 本地應用程序是在其上安裝並執行的公共客戶端 資源所有者使用的設備。協議數據和 資源所有者可以訪問證書。假定 包含在任何客戶端身份驗證憑證中 應用程序可以被提取。另一方面，動態地 頒發證書，如訪問令牌或刷新令牌可以 獲得可接受的保護水平。至少，這些 證書被保護免受敵方服務器的攻擊 應用程序可能會交互 在某些平台上，這些憑據 可能會受到其他應用程序的保護 設備。 。 授權服務器向注冊客戶端發出客戶端 標識符 - 表示注冊的唯一字符串 客戶提供的信息。客戶端標識符不是 秘密; 它暴露給資源所有者，不得使用 單獨用於客戶端認證。客戶端標識符是唯一的 授權服務器。 客戶端標識符字符串大小由此未定義 規范。客戶應該避免對此做出假設 標識符大小。授權服務器應該記錄大小 它發布的任何標識符。

 如果客戶類型是保密的，客戶和授權 服務器建立適合於客戶端的認證方法 授權服務器的安全要求。授權 服務器可以接受任何形式的客戶端認證 安全要求。 機密客戶通常發布（或建立）一組 客戶端憑證，用於與授權進行身份驗證 服務器（例如，密碼，公鑰/私鑰對）。 授權服務器可以建立客戶端認證方法 與公共客戶。但是，授權服務器不能依賴 在公共客戶端身份驗證上進行識別 客戶。 客戶端不得在每個中使用多個身份驗證方法 請求。 。 擁有客戶密碼的客戶可以使用HTTP Basic 認證方案在[ RFC2617 ]中進行了認證 授權服務器。客戶端標識符使用 “application / x-www-form-urlencoded”編碼算法 附錄B，編碼值用作用戶名; 客戶端 密碼使用相同的算法進行編碼並用作 密碼。授權服務器必須支持HTTP Basic 身份驗證方案，用於身份驗證客戶端已頒發a 客戶密碼。 例如（僅用於顯示目的的額外換行符）： 授權：基本czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 或者，授權服務器可以支持包括 請求主體中的客戶端憑證使用以下內容 參數： CLIENT_ID 需要。客戶端標識符在發送給客戶端的過程中第2.2節 所述的注冊過程。 client_secret 需要。客戶的秘密。客戶可以忽略 參數如果客戶端密碼是空字符串。

 使用這兩者在請求主體中包含客戶端憑證 不推薦使用參數，並且應該僅限於無法使用的客戶端 直接利用HTTP基本認證方案（或其他） 基於密碼的HTTP認證方案）。參數只能 在請求主體中傳送，不得包含在請求主體中 請求URI。 例如，使用一個請求刷新訪問令牌（第6節） 身體參數（帶有用於顯示目的的額外換行符 只要）： POST /令牌HTTP / 1.1 主機：server.example.com 內容類型：application / x-www-form-urlencoded grant_type = refresh_token＆refresh_token = tGzv3JOkF0XG5Qx2TlKWIA ＆CLIENT_ID = s6BhdRkqt3＆client_secret = 7Fjfp0ZBr1KtDRbnfVdmIw 授權服務器必須按要求使用TLS 使用密碼認證發送請求時，請參見1.6節。 由於此客戶端身份驗證方法涉及密碼，因此 授權服務器必須保護任何使用它的端點 蠻力攻擊。 。 授權服務器可以支持任何合適的HTTP認證 方案符合其安全要求。當使用其他 認證方法，授權服務器必須定義一個 客戶端標識符（注冊記錄）與之間的映射 認證方案。 。 本規范不排除使用未注冊的客戶端。 但是，這種客戶的使用超出了這個范圍 規范並需要額外的安全分析和審查 其互操作性的影響。

 授權過程使用兩個授權服務器端點 （HTTP資源）： o授權端點 - 客戶端用來獲取 通過用戶代理重定向從資源所有者獲得授權。 o令牌端點 - 由客戶端用來交換授權 授予訪問令牌，通常使用客戶端驗證。 以及一個客戶端端點： o重定向端點 - 授權服務器用於返回 包含授權憑證的響應通過客戶端 資源所有者用戶代理。 並非每個授權許可類型都使用兩個端點。 擴展授權類型可以根據需要定義附加端點。 。 授權端點用於與資源進行交互 所有者並獲得授權許可。授權服務器 必須首先驗證資源所有者的身份。在中的方式 授權服務器認證資源所有者 （例如，用戶名和密碼登錄，會話cookie）超出了 本規范的范圍。 客戶通過哪種方式獲得該地點的手段 授權端點超出了本規范的范圍， 但該位置通常在服務文檔中提供。 端點URI可以包含“application / x-www-form-urlencoded” 格式化（按附錄B）查詢組件（[RFC3986]第3.4節）， 當添加額外的查詢參數時必須保留這些參數。該 端點URI不能包含片段組件。 由於對授權端點的請求導致用戶 身份驗證和傳輸明文憑證（在 HTTP響應），授權服務器必須要求使用TLS 如第1.6節所述向請求發送請求時 授權端點。 授權服務器必須支持使用HTTP“GET” 方法[ RFC2616 ]授權端點，並可以支持 也使用“POST”方法。

 不帶值的發送參數必須被視為是 從請求中省略。授權服務器必須忽略 無法識別的請求參數。請求和響應參數 不得多於一次。 。 授權代碼授權使用授權端點 類型和隱式授權類型流程。客戶通知 使用以下方式獲得期望授權類型的授權服務器 參數： RESPONSE_TYPE 需要。該值必須是用於請求的“代碼”之一 授權碼，如第4.1.1節 “token”所述 請求訪問令牌（隱式授權），如所述 第4.2.1節或8.4節所述的注冊擴展值 。 擴展響應類型可能包含空格分隔的（％x20）列表 值，其中值的順序無關緊要（例如，響應 類型“a b”與“b a”相同）。這種復合材料的含義 響應類型由其各自的規格定義。 如果授權請求缺少“response_type”參數， 或者如果響應類型不理解，授權服務器 必須按4.1.2.1節所述返回錯誤響應。 。 在完成與資源所有者的交互之后， 授權服務器將資源所有者的用戶代理引導回 客戶端。授權服務器將用戶代理重定向到 客戶端的重定向端點以前與 授權服務器在客戶端注冊過程中或何時進行 作出授權請求。 重定向端點URI必須是由定義的絕對URI [RFC3986]第4.3節。端點URI可以包含一個 “application / x-www-form-urlencoded”格式化（按附錄B）查詢 組件（[RFC3986] 3.4節），它必須在添加時保留 額外的查詢參數。端點URI不能包含a 片段組件。

 重定向端點應該按照描述的要求使用TLS 在第1.6節中，當請求的響應類型是“代碼”或“令牌”時， 或者當重定向請求將導致傳輸時 敏感的憑據通過開放的網絡。本規范確實如此 不要求使用TLS，因為在撰寫本文時， 要求客戶部署TLS對許多人來說是一個重大障礙 客戶開發者。如果TLS不可用，則授權服務器 應該在之前警告資源所有者有關不安全的端點 重定向（例如，在授權期間顯示消息 請求）。 傳輸層安全性的缺乏可能會對系統造成嚴重影響 客戶端的安全性以及授權的受保護資源 訪問。特別是使用傳輸層安全性 批准過程作為一種形式使用時很關鍵 由客戶（例如，第三方）委托最終用戶認證 登錄服務）。 。 授權服務器必須要求以下客戶端 注冊他們的重定向端點： o公共客戶。 o使用隱式授權類型的機密客戶端。 授權服務器應該要求所有客戶端注冊它們 重定向端點在使用授權端點之前。 授權服務器應該要求客戶端提供 完整的重定向URI（客戶端可以使用“狀態”請求 參數來實現每個請求的定制）。如果需要的話 完整的重定向URI的注冊是不可能的， 授權服務器應該要求注冊URI 方案，權限和路徑（允許客戶動態變化 請求時只有重定向URI的查詢組件 授權）。 授權服務器可以允許客戶端注冊多個 重定向端點。 沒有重定向URI注冊要求可以啟用一個 攻擊者使用授權端點作為開放重定向器 如10.15節所述。

 如果多個重定向URI已被注冊，則只有部分 重定向URI已被注冊，或者沒有重定向URI 已被注冊，客戶端必須包含重定向URI 授權請求使用“redirect_uri”請求參數。 當重定向URI包含在授權請求中時， 授權服務器必須比較並匹配收到的值 針對至少一個注冊的重定向URI（或URI） 組件），如第6節中所定義，如果有任何重定向 URI已注冊。如果客戶注冊包括全部 重定向URI，授權服務器必須比較這兩個URI 使用第6.2.1節中定義的簡單字符串比較。 。 如果授權請求由於缺失而未通過驗證， 無效的或不匹配的重定向URI，即授權服務器 應該通知資源所有者該錯誤，並且不應該 自動將用戶代理重定向到無效的重定向URI。 。 對客戶端端點的重定向請求通常會導致 一個HTML文檔響應，由用戶代理處理。如果HTML 響應直接作為重定向請求的結果提供， 包含在HTML文檔中的任何腳本都將完整地執行 訪問重定向URI及其包含的憑證。 客戶端不應該包含任何第三方腳本（例如， 第三方分析，社交插件，廣告網絡） 端點響應。相反，它應該從中提取證書 該URI並將用戶代理重新定向到另一個沒有的端點 公開憑證（在URI或其他地方）。如果是第三方 包含腳本，客戶端必須確保自己的腳本 （用於從URI中提取和刪除證書）將會 先執行。 。 令牌端點由客戶端用來獲取訪問令牌 呈現其授權許可或刷新令牌。令牌 端點與每個授權許可一起使用，除了 隱式授權類型（因為訪問令牌直接發布）。

 客戶端通過其獲取令牌位置的方式 終點不在本規范的范圍內，而是位置 通常在服務文檔中提供。 端點URI可以包含“application / x-www-form-urlencoded” 格式化（按附錄B）查詢組件（[RFC3986]第3.4節）， 當添加額外的查詢參數時必須保留這些參數。該 端點URI不能包含片段組件。 由於對令牌端點的請求導致傳輸 明文憑證（在HTTP請求和響應中）， 授權服務器必須按要求使用TLS 向令牌端點發送請求時的第1.6節。 客戶端在創建訪問令牌時必須使用HTTP“POST”方法 要求。 不帶值的發送參數必須被視為是 從請求中省略。授權服務器必須忽略 無法識別的請求參數。請求和響應參數 不得多於一次。 。 機密客戶端或其他客戶端必須發布客戶端憑證 如授權服務器所述進行驗證 在向令牌端點發出請求時的第2.3節。客戶 身份驗證用於： o強制刷新令牌和授權代碼綁定到 他們發給的客戶。客戶端身份驗證很關鍵 當授權碼被發送到重定向時 端點通過不安全的通道或重定向URI時 未完全注冊。 o通過禁用客戶端或服務器從受損客戶端恢復 更改憑據，從而防止攻擊者濫用 被盜的刷新令牌。更改一組客戶端 憑證要比撤銷整套憑證要快得多 刷新令牌。 o實施認證管理最佳實踐， 需要定期憑證輪換。旋轉整個集合 的刷新令牌可能具有挑戰性，而旋轉一個單一的 客戶端憑據集非常容易。

 客戶端可以使用“client_id”請求參數來標識自己 向令牌端點發送請求時。在里面 對授權端點的“authorization_code”“grant_type”請求， 未經身份驗證的客戶端必須發送其“client_id”以防止其本身 從無意中接受用於客戶端的代碼 不同的“client_id”。這可以保護客戶免受替代 認證碼。（它不提供額外的安全性 受保護的資源。） 。 授權和令牌端點允許客戶端指定 訪問請求的范圍使用“范圍”請求參數。在 轉，授權服務器使用“范圍”響應參數 通知客戶端發出的訪問令牌的范圍。 scope參數的值表示為空間 - 分隔的，區分大小寫的字符串。字符串由 授權服務器。如果該值包含多個由空格分隔的值 字符串，它們的順序無關緊要，每個字符串都會添加一個 請求范圍的額外訪問范圍。 scope = scope-token *（SP scope-token） scope-token = 1 *（％x21 /％x23-5B /％x5D-7E） 授權服務器可以完全或部分地忽略范圍 由客戶端根據授權服務器策略或 資源所有者的指示。如果發出訪問令牌的范圍 與客戶請求的授權不同 服務器必須包含“范圍”響應參數來通知 授予實際范圍的客戶。 如果客戶請求時忽略范圍參數 授權，授權服務器必須或者處理 請求使用預定義的默認值或請求失敗 表明無效范圍。授權服務器應該 記錄其范圍要求和默認值（如果已定義）。 。 要請求訪問令牌，客戶端會從中獲得授權 資源所有者。授權以表格形式表示 授權許可，客戶用來請求訪問 令牌。OAuth定義了四種授權類型：授權代碼，隱式， 資源所有者密碼憑證和客戶端憑證。它也是 提供了一個定義附加授權類型的擴展機制。

 授權碼授權類型用於獲取兩個訪問權限 令牌和刷新令牌，並針對機密客戶進行了優化。 由於這是一個基於重定向的流程，因此客戶端必須有能力 與資源所有者的用戶代理（通常是web）進行交互 瀏覽器）並且能夠接收傳入請求（通過重定向） 來自授權服務器。 + ---------- + | 資源| | 所有者| | | + ---------- + ^ | （B） + ---- | ----- +客戶端標識符+ --------------- + | - + ----（A） - ＆重定向URI ----> | | | User- | | 授權| | 代理 - + ----（B） - 用戶認證---> | 服務器| | | | | | - + ----（C） - 授權碼--- <| | + - | ---- | --- + + --------------- + | | ^ v （A）（C）| | | | | | ^ v | | + --------- + | | | |> ---（D） - 授權碼---------'| | 客戶端| ＆重定向URI | | | | | | <---（E）-----訪問令牌-------------------' + --------- +（w /可選刷新令牌） 注：說明步驟（A），（B）和（C）的線條被分解為 兩部分通過用戶代理。 圖3：授權碼流程

 圖3所示的流程包括以下步驟： （A）客戶通過指導資源所有者來啟動流程 用戶代理到授權端點。客戶包括 其客戶端標識符，請求范圍，本地狀態和a 重定向URI，授權服務器將發送該URI 一旦訪問被授予（或拒絕），用戶代理回來。 （B）授權服務器認證資源所有者（通過 用戶代理）並建立資源所有者 授予或拒絕客戶的訪問請求。 （C）假設資源所有者授予訪問權限，授權 服務器將用戶代理重定向回客戶端使用 重定向URI先前提供（在請求中或在 客戶注冊）。重定向URI包含一個 授權碼和客戶提供的任何本地狀態 早。 （D）客戶端從授權中請求訪問令牌 服務器的令牌端點包含授權碼 在上一步中收到。在提出請求時， 客戶端與授權服務器進行身份驗證。客戶端 包括用於獲取授權的重定向URI 代碼驗證。 （E）授權服務器認證客戶端，驗證 授權碼，並確保重定向URI 收到的匹配用於重定向客戶端的URI 步驟（C）。如果有效，授權服務器回應 訪問令牌和可選的刷新令牌。 。 客戶端通過添加以下內容來構造請求URI 參數傳遞給授權端點URI的查詢組件 使用“application / x-www-form-urlencoded”格式，按照附錄B： RESPONSE_TYPE 需要。值必須設置為“代碼”。 CLIENT_ID 需要。客戶端標識符如2.2節所述。 REDIRECT_URI 可選的。如3.1.2節所述。

 范圍 可選的。訪問請求的范圍如所描述 第3.3節。 州 推薦的。客戶用來維護的一個不透明的值 請求和回調之間的狀態。授權 服務器在重定向用戶代理時包含此值 給客戶。該參數應該用於防止 如第10.12節所述的跨站請求偽造。 客戶端使用一個指向資源所有者的URI HTTP重定向響應，或通過其他可用的方式 用戶代理。 例如，客戶端指示用戶代理進行以下操作 使用TLS的HTTP請求（帶顯示目的的額外換行符 只要）： GET / authorize？response_type = code＆client_id = s6BhdRkqt3＆state = xyz ＆redirect_uri = https％3A％2F％2Fclient％2Eexample％2Ecom％2Fcb HTTP / 1.1 主機：server.example.com 授權服務器驗證請求以確保全部 所需參數存在且有效。如果請求有效， 授權服務器認證資源所有者並獲得 授權決定（通過詢問資源所有者或通過 通過其他方式建立批准）。 當決定建立時，授權服務器指示 用戶代理使用HTTP提供的客戶端重定向URI 重定向響應，或通過其他可用的方式 用戶代理。 。 如果資源所有者授予訪問請求，授權 服務器發出一個授權碼，並通過它傳遞給客戶端 將以下參數添加到。的查詢組件 使用“application / x-www-form-urlencoded”格式的重定向URI， 根據附錄B： 碼 需要。由生成的授權碼 授權服務器。授權碼必須過期 發布后不久，以減少泄漏的風險。一個 最長授權碼的使用壽命為10分鍾 推薦的。客戶端不得使用授權碼

 不止一次。如果使用授權碼超過 一旦授權服務器必須拒絕該請求並應該 撤銷（如果可能）基於以前發布的所有令牌 該授權碼。授權碼綁定到 客戶端標識符和重定向URI。 州 如果客戶端中存在“狀態”參數，則需要 授權請求。收到的確切價值 客戶。 例如，授權服務器通過重定向用戶代理 發送以下HTTP響應： HTTP / 1.1 302找到 位置：https：//client.example.com/cb？code = SplxlOBeZQQYbYS6WxSbIA ＆狀態= XYZ 客戶端必須忽略無法識別的響應參數。該 授權碼字符串大小由此未定義 規范。客戶應該避免對代碼做出假設 值大小。授權服務器應該記錄文件的大小 它發布的任何價值。 。 如果請求由於缺失，無效或不匹配而失敗 重定向URI，或者如果客戶端標識符丟失或無效， 授權服務器應該通知資源所有者 錯誤，並且不能自動將用戶代理重定向到 無效的重定向URI。 如果資源所有者拒絕訪問請求或請求 除了丟失或無效的重定向URI以外的原因失敗， 授權服務器通過添加以下內容來通知客戶端 使用參數到重定向URI的查詢組件 “application / x-www-form-urlencoded”格式，根據附錄B： 錯誤 需要。單個ASCII碼[ USASCII ]錯誤代碼 以下： 無效的請求 該請求缺少必需的參數，包括一個 無效的參數值，包含多個參數 一次或以其他方式變形

 unauthorized_client 客戶無權請求授權 代碼使用這種方法。 拒絕訪問 資源所有者或授權服務器拒絕 請求。 unsupported_response_type 授權服務器不支持獲取 使用此方法的授權碼。 invalid_scope 請求的范圍無效，未知或格式錯誤。 服務器錯誤 授權服務器遇到意外情況 條件阻止它履行請求。 （由於500內部服務器，需要此錯誤代碼 錯誤HTTP狀態碼無法返回給客戶端 通過HTTP重定向。） 暫時不可用 授權服務器當前無法處理 該請求由於臨時超載或維護而發生 的服務器。（這個錯誤代碼是需要的，因為503 服務不可用HTTP狀態碼無法返回 通過HTTP重定向到客戶端。） “error”參數的值不能包含字符 超出設定值％x20-21 /％x23-5B /％x5D-7E。 ERROR_DESCRIPTION 可選的。提供人類可讀的ASCII [ USASCII ]文本 附加信息，用於協助客戶開發人員 了解發生的錯誤。 “error_description”參數的值不能包含 設置％x20-21 /％x23-5B /％x5D-7E之外的字符。 error_uri 可選的。一個URI，用於識別一個可讀的網頁 有關錯誤的信息，用於提供客戶端 開發人員提供有關錯誤的其他信息。 “error_uri”參數的值必須符合 URI參考語法，因此不能包含字符 超出設定值％x21 /％x23-5B /％x5D-7E。

 如果客戶端中存在“狀態”參數則需要 授權請求。收到的確切價值 客戶。 例如，授權服務器通過重定向用戶代理 發送以下HTTP響應： HTTP / 1.1 302找到 位置：https://client.example.com/cb?error=access_denied&state=xyz 。 客戶端通過發送請求給令牌端點 以下參數使用“application / x-www-form-urlencoded” 格式，每個附錄B在HTTP中使用UTF-8字符編碼 請求實體主體： grant_type 需要。值必須設置為“authorization_code”。 碼 需要。從收到的授權碼 授權服務器。 REDIRECT_URI 要求，如果“redirect_uri”參數包含在 如第4.1.1節所述的授權請求，以及它們的 值必須相同。 CLIENT_ID 要求，如果客戶端沒有通過身份驗證 授權服務器，如第3.2.1節所述。 如果客戶端類型是保密的或者客戶端是客戶端 憑證（或分配其他認證要求）， 客戶端必須按照描述向授權服務器進行認證 在3.2.1節中。

 例如，客戶端使用TLS發出以下HTTP請求 （僅用於顯示目的額外換行符）： POST /令牌HTTP / 1.1 主機：server.example.com 授權：基本czZCaGRSa3F0MzpnWDFmQmF0M2JW 內容類型：application / x-www-form-urlencoded grant_type = authorization_code＆代碼= SplxlOBeZQQYbYS6WxSbIA ＆REDIRECT_URI = HTTPS％3A％2F％2Fclient％2Eexample％2Ecom％2Fcb 授權服務器必須： o要求機密客戶或任何客戶進行客戶認證 客戶端頒發了客戶端證書（或與其他客戶端 認證要求）， o如果包含客戶端認證，則認證客戶端， o確保授權代碼已頒發給經過身份驗證的代碼 保密的客戶，或者如果客戶是公開的，確保 代碼被發送到請求中的“client_id” o驗證授權碼是否有效，並且 o確保“redirect_uri”參數存在 “redirect_uri”參數包含在初始授權中 請求，如4.1.1節所述，並且如果包含的話確保 它們的值是相同的。 如果訪問令牌請求是有效和授權的， 授權服務器發出訪問令牌和可選刷新 令牌，如5.1節所述。如果請求客戶端 認證失敗或無效，授權服務器返回 如第5.2節所述的錯誤響應。

 一個成功的例子： HTTP / 1.1 200 OK Content-Type：application / json; charset = UTF-8 緩存控制：無存儲 Pragma：無緩存 { “ACCESS_TOKEN”： “2YotnFZFEjr1zCsicMWpAA” “token_type”： “例如”， “expires_in”：3600， “refresh_token”： “tGzv3JOkF0XG5Qx2TlKWIA” “example_parameter”： “example_value” } 隱式授權類型用於獲取訪問令牌（它不會 支持刷新令牌的發行）並且為公眾優化 已知可以操作特定重定向URI的客戶端。這些客戶 通常使用腳本語言在瀏覽器中實現 如JavaScript。 由於這是一個基於重定向的流程，因此客戶端必須有能力 與資源所有者的用戶代理（通常是web）進行交互 瀏覽器）並且能夠接收傳入請求（通過重定向） 來自授權服務器。 不同於客戶制作的授權代碼授權類型 單獨的授權請求和訪問令牌 客戶端根據授權接收訪問令牌 請求。 隱式授權類型不包括客戶端認證，並且 依賴資源所有者的存在和注冊 重定向URI。因為訪問令牌被編碼為 重定向URI，它可能會暴露給資源所有者和其他人 應用程序駐留在同一設備上。

 + ---------- + | 資源| | 所有者| | | + ---------- + ^ | （B） + ---- | ----- +客戶端標識符+ --------------- + | - + ----（A） - ＆重定向URI ---> | | | User- | | 授權| | 代理 - | ----（B） - 用戶認證 - > | 服務器| | | | | | | <---（C）---重定向URI ---- <| | | | 使用Access Token + --------------- + | | 在片段 | | + --------------- + | | ----（D）---重定向URI ----> | 網絡托管| | | 沒有片段| 客戶端| | | | 資源| | （F）| <---（E）-------腳本--------- <| | | | + --------------- + + - | -------- + | | （A）（G）訪問令牌 | | ^ v + --------- + | | | 客戶端| | | + --------- + 注：說明步驟（A）和（B）的線條被分成兩部分 部分，因為他們通過用戶代理。 圖4：隱式授權流程

   圖4中所示的流程包括以下步驟：

   （A）客戶通過指導資源所有者來啟動流程
        用戶代理到授權端點。客戶包括
        其客戶端標識符，請求范圍，本地狀態和a
        重定向URI，授權服務器將發送該URI
        一旦訪問被授予（或拒絕），用戶代理回來。

   （B）授權服務器認證資源所有者（通過
        用戶代理）並建立資源所有者
        授予或拒絕客戶的訪問請求。

   （C）假設資源所有者授予訪問權限，授權
        服務器將用戶代理重定向回客戶端使用
        之前提供的重定向URI。重定向URI包括
        URI片段中的訪問令牌。

   （D）用戶代理通過制作a來遵循重定向指示
        請求到網絡托管的客戶端資源（不
        包括每個[ RFC2616 ] 的片段）。用戶代理保留
        片段信息在本地。

   （五）網絡托管的客戶端資源返回一個網頁（通常是
        帶有嵌入腳本的HTML文檔）能夠訪問
        完整的重定向URI，包括由。保留的片段
        用戶代理，並提取訪問令牌（和其他
        參數）包含在片段中。

   （F）用戶代理執行由網站托管的腳本
        本地客戶端資源，它提取訪問令牌。

   （G）用戶代理將訪問令牌傳遞給客戶端。

   有關使用隱式授權的背景，請參見第1.3.2和第9節。出於重要的安全考慮，
   請參閱第10.3和10.16節
   當使用隱式授權時。

。 客戶端通過添加以下內容來構造請求URI 參數傳遞給授權端點URI的查詢組件 使用“application / x-www-form-urlencoded”格式，按照附錄B： RESPONSE_TYPE 需要。值必須設置為“標記”。 CLIENT_ID 需要。客戶端標識符如2.2節所述。

 REDIRECT_URI 可選的。如3.1.2節所述。 范圍 可選的。訪問請求的范圍如所描述 第3.3節。 州 推薦的。客戶用來維護的一個不透明的值 請求和回調之間的狀態。授權 服務器在重定向用戶代理時包含此值 給客戶。該參數應該用於防止 如第10.12節所述的跨站請求偽造。 客戶端使用一個指向資源所有者的URI HTTP重定向響應，或通過其他可用的方式 用戶代理。 例如，客戶端指示用戶代理進行以下操作 使用TLS的HTTP請求（帶顯示目的的額外換行符 只要）： GET / authorize？response_type = token＆client_id = s6BhdRkqt3＆state = xyz ＆redirect_uri = https％3A％2F％2Fclient％2Eexample％2Ecom％2Fcb HTTP / 1.1 主機：server.example.com 授權服務器驗證請求以確保全部 所需參數存在且有效。授權服務器 必須驗證它將重定向到的重定向URI 訪問令牌與由客戶端注冊的重定向URI相匹配 如3.1.2節所述。 如果請求有效，授權服務器將認證該請求 資源所有者並獲得授權決定（通過詢問 資源所有者或通過其他方式建立批准）。 當決定建立時，授權服務器指示 用戶代理使用HTTP提供的客戶端重定向URI 重定向響應，或通過其他可用的方式 用戶代理。

 如果資源所有者授予訪問請求，授權 服務器發出訪問令牌並通過添加將其傳遞給客戶端 以下參數用於重定向的片段組件 使用“application / x-www-form-urlencoded”格式的URI 附錄B： 的access_token 需要。訪問令牌由授權服務器發出。 token_type 需要。按照中所述發放令牌的類型 第7.1節。值不區分大小寫。 過期日期在 推薦的。訪問令牌的生存時間（秒）。對於 例如，值“3600”表示訪問令牌將會 從響應生成的一小時內到期。 如果省略，授權服務器應該提供 通過其他方式的到期時間或記錄默認值。 范圍 可選，如果與客戶要求的范圍相同; 否則，需要。訪問令牌的范圍為 由第3.3節描述。 州 如果客戶端中存在“狀態”參數，則需要 授權請求。收到的確切價值 客戶。 授權服務器不得發布刷新令牌。 例如，授權服務器通過重定向用戶代理 發送以下HTTP響應（帶有額外的換行符） 僅用於顯示目的）： HTTP / 1.1 302找到 地點：http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA ＆狀態= XYZ＆token_type =示例＆expires_in = 3600 開發人員應該注意到一些用戶代理不支持 在HTTP“位置”響應中包含碎片組件 標題字段。這些客戶需要使用其他方法 重定向客戶端比3xx重定向響應 - for 例如，返回包含“繼續”按鈕的HTML頁面 通過鏈接到重定向URI的操作。

 客戶端必須忽略無法識別的響應參數。訪問 標記字符串的大小在本規范中未定義。該 客戶應該避免對價值規模做出假設。該 授權服務器應該記錄它發布的任何值的大小。 如果請求由於缺失，無效或不匹配而失敗 重定向URI，或者如果客戶端標識符丟失或無效， 授權服務器應該通知資源所有者 錯誤，並且不能自動將用戶代理重定向到 無效的重定向URI。 如果資源所有者拒絕訪問請求或請求 除了丟失或無效的重定向URI以外的原因失敗， 授權服務器通過添加以下內容來通知客戶端 使用參數指向重定向URI的片段組件 “application / x-www-form-urlencoded”格式，根據附錄B： 錯誤 需要。單個ASCII碼[ USASCII ]錯誤代碼 以下： 無效的請求 該請求缺少必需的參數，包括一個 無效的參數值，包含多個參數 一次或以其他方式變形。 unauthorized_client 客戶端無權請求訪問令牌 使用這種方法。 拒絕訪問 資源所有者或授權服務器拒絕 請求。 unsupported_response_type 授權服務器不支持獲取 使用此方法訪問令牌。 invalid_scope 請求的范圍無效，未知或格式錯誤。

 服務器錯誤 授權服務器遇到意外情況 條件阻止它履行請求。 （由於500內部服務器，需要此錯誤代碼 錯誤HTTP狀態碼無法返回給客戶端 通過HTTP重定向。） 暫時不可用 授權服務器當前無法處理 該請求由於臨時超載或維護而發生 的服務器。（這個錯誤代碼是需要的，因為503 服務不可用HTTP狀態碼無法返回 通過HTTP重定向到客戶端。） “error”參數的值不能包含字符 超出設定值％x20-21 /％x23-5B /％x5D-7E。 ERROR_DESCRIPTION 可選的。提供人類可讀的ASCII [ USASCII ]文本 附加信息，用於協助客戶開發人員 了解發生的錯誤。 “error_description”參數的值不能包含 設置％x20-21 /％x23-5B /％x5D-7E之外的字符。 error_uri 可選的。一個URI，用於識別一個可讀的網頁 有關錯誤的信息，用於提供客戶端 開發人員提供有關錯誤的其他信息。 “error_uri”參數的值必須符合 URI參考語法，因此不能包含字符 超出設定值％x21 /％x23-5B /％x5D-7E。 州 如果客戶端中存在“狀態”參數則需要 授權請求。收到的確切價值 客戶。 例如，授權服務器通過重定向用戶代理 發送以下HTTP響應： HTTP / 1.1 302找到 位置：https：//client.example.com/cb#error=access_denied&state=xyz 資源所有者密碼憑據授權類型適用於 資源所有者與信任關系的情況 客戶端，例如設備操作系統或高度特權的客戶端

 應用。授權服務器應特別小心 啟用此授權類型並僅在其他流程不允許時才允許 可行的。 這種授予類型適用於能夠獲得該授權的客戶 資源所有者的憑據（用戶名和密碼，通常使用 一個交互式表單）。它也用於遷移現有的客戶端 使用直接認證方案，如HTTP Basic或Digest 通過將存儲的憑證轉換為OAuth來驗證OAuth 訪問令牌。 + ---------- + | 資源| | 所有者| | | + ---------- + v | 資源所有者 （A）密碼憑證 | v + --------- + + --------------- + | |> - （B）----資源所有者-------> | | | | 密碼憑證| 授權| | 客戶端| | 服務器| | | < - （C）----訪問令牌--------- <| | | | （w /可選刷新令牌）| | + --------- + + --------------- + 圖5：資源所有者密碼憑證流程 圖5中所示的流程包括以下步驟： （A）資源所有者向客戶提供其用戶名和密碼 密碼。 （B）客戶端從授權中請求訪問令牌 服務器的令牌端點通過包括收到的憑證 來自資源所有者。當提出請求時，客戶端 與授權服務器進行身份驗證。 （C）授權服務器認證客戶端並驗證 資源所有者憑據，如果有效，則發出訪問 令牌。

 客戶端獲取資源所有者的方法 憑證超出了本規范的范圍。客戶端 必須在獲得訪問令牌后丟棄憑證。  客戶端通過添加該請求來向令牌端點發出請求 以下參數使用“application / x-www-form-urlencoded” 格式，每個附錄B在HTTP中使用UTF-8字符編碼 請求實體主體： grant_type 需要。值必須設置為“密碼”。 用戶名 需要。資源所有者用戶名。 密碼 需要。資源所有者密碼。 范圍 可選的。訪問請求的范圍如所描述 第3.3節。 如果客戶端類型是保密的或者客戶端是客戶端 憑證（或分配其他認證要求）， 客戶端必須按照描述向授權服務器進行認證 在3.2.1節中。 例如，客戶端使用以下HTTP請求 傳輸層安全性（用於顯示目的的額外換行符 只要）： POST /令牌HTTP / 1.1 主機：server.example.com 授權：基本czZCaGRSa3F0MzpnWDFmQmF0M2JW 內容類型：application / x-www-form-urlencoded grant_type =密碼＆用戶名=輸入johndoe＆密碼= A3ddj3w

 授權服務器必須： o要求機密客戶或任何客戶進行客戶認證 客戶端頒發了客戶端證書（或與其他客戶端 認證要求）， o如果客戶端認證包含在內，則認證客戶端 o使用其驗證資源所有者密碼憑證 現有的密碼驗證算法。 由於此訪問令牌請求使用資源所有者的請求 密碼，授權服務器必須保護端點 蠻力攻擊（例如，使用限速或生成 警報）。  如果訪問令牌請求是有效和授權的， 授權服務器發出訪問令牌和可選刷新 令牌，如5.1節所述。如果請求失敗的客戶端 認證或無效，授權服務器返回一個 錯誤響應如第5.2節所述。 一個成功的例子： HTTP / 1.1 200 OK Content-Type：application / json; charset = UTF-8 緩存控制：無存儲 Pragma：無緩存 { “ACCESS_TOKEN”： “2YotnFZFEjr1zCsicMWpAA” “token_type”： “例如”， “expires_in”：3600， “refresh_token”： “tGzv3JOkF0XG5Qx2TlKWIA” “example_parameter”： “example_value” } 。 客戶端可以僅使用其客戶端請求訪問令牌 憑證（或其他支持的認證方式） 客戶端正在請求訪問其下的受保護資源 控制，或其他資源所有者以前的控制權 與授權服務器一起安排（其方法超越 本規范的范圍）。

 客戶機證書授權類型只能用於保密 客戶端。 + --------- + + --------------- + | | | | | |> - （A） - 客戶端身份驗證---> | 授權| | 客戶端| | 服務器| | | < - （B）----訪問令牌--------- <| | | | | | + --------- + + --------------- + 圖6：客戶端憑證流程 圖6所示的流程包括以下步驟： （A）客戶端與授權服務器進行身份驗證 從令牌端點請求訪問令牌。 （B）授權服務器認證客戶端，如果有效， 發出訪問令牌。  由於客戶端認證被用作授權許可， 不需要額外的授權請求。  客戶端通過添加該請求來向令牌端點發出請求 以下參數使用“application / x-www-form-urlencoded” 格式，每個附錄B在HTTP中使用UTF-8字符編碼 請求實體主體： grant_type 需要。值必須設置為“client_credentials”。 范圍 可選的。訪問請求的范圍如所描述 第3.3節。 客戶端必須與授權服務器進行身份驗證 如3.2.1節所述。

 例如，客戶端使用以下HTTP請求 傳輸層安全性（用於顯示目的的額外換行符 只要）： POST /令牌HTTP / 1.1 主機：server.example.com 授權：基本czZCaGRSa3F0MzpnWDFmQmF0M2JW 內容類型：application / x-www-form-urlencoded grant_type = client_credentials 授權服務器必須驗證客戶端。  如果訪問令牌請求是有效和授權的， 授權服務器按照中所述發布訪問令牌 第5.1節。刷新令牌不應包含在內。如果請求 失敗的客戶端身份驗證或無效的授權服務器 返回第5.2節所述的錯誤響應。 一個成功的例子： HTTP / 1.1 200 OK Content-Type：application / json; charset = UTF-8 緩存控制：無存儲 Pragma：無緩存 { “ACCESS_TOKEN”： “2YotnFZFEjr1zCsicMWpAA” “token_type”： “例如”， “expires_in”：3600， “example_parameter”： “example_value” } 。 客戶端通過指定授予類型來使用擴展授權類型 使用絕對URI（由授權服務器定義）作為 令牌端點的“grant_type”參數的值，以及 添加必要的任何附加參數。

 例如，使用安全聲明請求訪問令牌 標記語言（SAML）2.0斷言授權類型，如定義的 [ OAuth-SAML2 ]，客戶端可以使用下面的HTTP請求 TLS（僅用於顯示目的附加換行符）： POST /令牌HTTP / 1.1 主機：server.example.com 內容類型：application / x-www-form-urlencoded grant_type =瓮％3Aietf％3Aparams％3Aoauth％3Agrant型％3Asaml2- 承載＆斷言= PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU [...為簡潔起見省略...] aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 如果訪問令牌請求是有效和授權的， 授權服務器發出訪問令牌和可選刷新 令牌，如5.1節所述。如果請求失敗的客戶端 認證或無效，授權服務器返回一個 錯誤響應如第5.2節所述。 。 如果訪問令牌請求是有效和授權的， 授權服務器發出訪問令牌和可選刷新 令牌，如5.1節所述。如果請求失敗的客戶端 認證或無效，授權服務器返回一個 錯誤響應如第5.2節所述。 。 授權服務器發出訪問令牌和可選的刷新 令牌，並通過添加以下參數來構建響應 到200（OK）狀態碼的HTTP響應的實體主體： 的access_token 需要。訪問令牌由授權服務器發出。 token_type 需要。按照中所述發放令牌的類型 第7.1節。值不區分大小寫。 過期日期在 推薦的。訪問令牌的生存時間（秒）。對於 例如，值“3600”表示訪問令牌將會 從響應生成的一小時內到期。 如果省略，授權服務器應該提供 通過其他方式的到期時間或記錄默認值。

 refresh_token 可選的。刷新令牌，可用於獲取新的 使用與描述相同的授權許可訪問令牌 在第6節。 范圍 可選，如果與客戶要求的范圍相同; 否則，需要。訪問令牌的范圍為 由第3.3節描述。 這些參數包含在HTTP響應的實體主體中 使用[ RFC4627 ] 定義的“application / json”媒體類型。該 參數被序列化為JavaScript對象表示法（JSON） 結構通過在最高結構級別添加每個參數。 JSON字符串包含參數名稱和字符串值。 數字值包含為JSON數字。的順序 參數無關緊要，可以改變。 授權服務器必須包含HTTP“Cache-Control” 響應頭字段[ RFC2616 ]，其值為“no-store” 包含令牌，憑證或其他敏感信息的響應 信息以及“Pragma”響應標題字段[ RFC2616 ] 值為“no-cache”。 例如： HTTP / 1.1 200 OK Content-Type：application / json; charset = UTF-8 緩存控制：無存儲 Pragma：無緩存 { “ACCESS_TOKEN”： “2YotnFZFEjr1zCsicMWpAA” “token_type”： “例如”， “expires_in”：3600， “refresh_token”： “tGzv3JOkF0XG5Qx2TlKWIA” “example_parameter”： “example_value” } 客戶端必須忽略響應中無法識別的值名稱。該 從授權接收的令牌和其他值的大小 服務器未定義。客戶應該避免制作 關於價值規模的假設。授權服務器應該 記錄它發布的任何價值的大小。

 授權服務器響應一個HTTP 400（錯誤請求） 狀態碼（除非另有規定）並包括以下內容 參數與響應： 錯誤 需要。單個ASCII碼[ USASCII ]錯誤代碼 以下： 無效的請求 該請求缺少必需的參數，包括一個 不受支持的參數值（授予類型除外）， 重復一個參數，包括多個憑證， 利用多種機制來認證 客戶端，或以其他方式格式不正確。 invalid_client 客戶端身份驗證失敗（例如，未知客戶端， 包含客戶端身份驗證，或不受支持 身份驗證方法）。授權服務器可以 返回一個HTTP 401（未授權）狀態碼來表示 哪些HTTP認證方案被支持。如果 客戶端嘗試通過“授權”進行身份驗證 請求頭字段，授權服務器必須 使用HTTP 401（未授權）狀態碼進行響應 包括“WWW-Authenticate”響應標題字段 匹配客戶端使用的認證方案。 invalid_grant 提供的授權許可（例如，授權 代碼，資源所有者憑據）或刷新令牌 無效，過期，已撤銷，與重定向不匹配 授權請求中使用的URI，或發布給的URI 另一個客戶。 unauthorized_client 經過身份驗證的客戶端無權使用此功能 授權許可類型。 unsupported_grant_type 該授權許可類型不受支持 授權服務器。

 invalid_scope 請求的范圍無效，未知，格式不正確或 超出資源所有者授予的范圍。 “error”參數的值不能包含字符 超出設定值％x20-21 /％x23-5B /％x5D-7E。 ERROR_DESCRIPTION 可選的。提供人類可讀的ASCII [ USASCII ]文本 附加信息，用於協助客戶開發人員 了解發生的錯誤。 “error_description”參數的值不能包含 設置％x20-21 /％x23-5B /％x5D-7E之外的字符。 error_uri 可選的。一個URI，用於識別一個可讀的網頁 有關錯誤的信息，用於提供客戶端 開發人員提供有關錯誤的其他信息。 “error_uri”參數的值必須符合 URI參考語法，因此不能包含字符 超出設定值％x21 /％x23-5B /％x5D-7E。 這些參數包含在HTTP響應的實體主體中 使用[ RFC4627 ] 定義的“application / json”媒體類型。該 通過添加每個參數將參數序列化為JSON結構 參數在最高結構級別。參數名稱和字符串 值包含為JSON字符串。包括數值 作為JSON數字。參數的順序並不重要，可以 變化。 例如： HTTP / 1.1 400錯誤請求 Content-Type：application / json; charset = UTF-8 緩存控制：無存儲 Pragma：無緩存 { “錯誤”： “INVALID_REQUEST” }

 如果授權服務器向客戶端發出刷新令牌，則 客戶端通過添加一個對令牌端點進行刷新請求 以下參數使用“application / x-www-form-urlencoded” 格式 grant_type 需要。值必須設置為“refresh_token”。 refresh_token 需要。刷新令牌發布給客戶端。 范圍 可選的。訪問請求的范圍如所描述 第3.3節。請求的范圍不得包含任何范圍 最初不是由資源所有者授予的，如果省略的話 視為等同於最初授予的范圍 資源所有者。 因為刷新令牌通常是持久的憑證 請求額外的訪問令牌，刷新令牌綁定到 它發布的客戶。如果客戶類型是保密的或 客戶端被頒發了客戶端證書（或分配給他人） 認證要求），客戶端必須通過認證 授權服務器，如第3.2.1節所述。 例如，客戶端使用以下HTTP請求 傳輸層安全性（用於顯示目的的額外換行符 只要）： POST /令牌HTTP / 1.1 主機：server.example.com 授權：基本czZCaGRSa3F0MzpnWDFmQmF0M2JW 內容類型：application / x-www-form-urlencoded grant_type = refresh_token＆refresh_token = tGzv3JOkF0XG5Qx2TlKWIA

 授權服務器必須： o要求機密客戶或任何客戶進行客戶認證 客戶端頒發了客戶端證書（或與其他客戶端 認證要求）， o如果包含客戶端認證，則認證客戶端 確保刷新令牌已頒發給已認證的用戶 客戶端和 o驗證刷新令牌。 如果有效且授權，則授權服務器發出訪問 令牌，如5.1節所述。如果請求失敗 驗證或無效，授權服務器返回錯誤 如第5.2節所述。 在這種情況下，授權服務器可以發出新的刷新令牌 客戶端必須丟棄舊的刷新令牌並用它替換它 新的刷新令牌。授權服務器可以撤銷舊的 在向客戶端發出新的刷新令牌后刷新令牌。如果一個 新的刷新令牌被發出，刷新令牌范圍必須是 與客戶端包含的刷新令牌相同 請求。  客戶端通過呈現訪問來訪問受保護的資源 令牌給資源服務器。資源服務器必須驗證 訪問令牌並確保它沒有過期並且它的范圍 涵蓋了所請求的資源。資源使用的方法 服務器驗證訪問令牌（以及任何錯誤響應） 超出了本規范的范圍，但通常涉及到一個 資源服務器和服務器之間的交互或協調 授權服務器。 客戶端使用訪問令牌的方法 使用資源服務器進行身份驗證取決於訪問類型 令牌由授權服務器發出。通常情況下，它涉及 使用HTTP“Authorization”請求頭域[ RFC2617 ]和 認證方案由訪問規范定義 使用的令牌類型，如[ RFC6750 ]。

 訪問令牌類型向客戶端提供信息 要求成功使用訪問令牌來進行保護 資源請求（以及類型特定的屬性）。客戶端 如果不了解令牌，則不能使用訪問令牌 類型。 例如，使用[ RFC6750 ]中定義的“承載”令牌類型 只需在請求中包含訪問令牌字符串即可： GET / resource / 1 HTTP / 1.1 主持人：example.com 授權：持票人mF_9.B5f-4.1JqM 而[ OAuth-HTTP-MAC ]中定義的“mac”令牌類型則被使用 一起發送消息認證碼（MAC）密鑰 訪問令牌，用於簽署HTTP的某些組件 要求： GET / resource / 1 HTTP / 1.1 主持人：example.com 授權：MAC id =“h480djs93hd8”， 隨機數= “274312：dj83hs9s”， MAC = “kDZvddkndxvhGRXZhvuDjEWhGeE =” 上述例子僅用於說明目的。 建議開發者參考[ RFC6750 ]和[ OAuth-HTTP-MAC ] 使用前的規格。 每個訪問令牌類型定義都指定了其他屬性 （如果有）與“access_token”響應一起發送給客戶端 參數。它還定義了用於的HTTP認證方法 在進行受保護的資源請求時包括訪問令牌。  如果資源訪問請求失敗，資源服務器應該通知 錯誤的客戶端。盡管這些錯誤反應的細節 超出了本規范的范圍，本文件規定第11.4節中的 一個共同注冊表，用於共享錯誤值 OAuth令牌認證方案。 新的身份驗證方案主要針對OAuth令牌設計 認證應該定義一個提供錯誤的機制 狀態碼給客戶端，其中允許的錯誤值是 注冊在本規范建立的錯誤注冊表中。

 這樣的方案可以將有效的錯誤代碼集合限制為一個子集 注冊值。如果錯誤代碼是使用named返回的 參數，參數名稱應該是“錯誤”。 其他能夠用於OAuth令牌認證的方案， 但不是主要為此目的設計的，可以約束他們的錯誤 值以相同的方式注冊到注冊表。 新的認證方案可以選擇也指定使用 “error_description”和“error_uri”參數返回錯誤 信息的方式與它們在此的使用方式相平行 規范。  訪問令牌類型可以通過以下兩種方式之一進行定義：注冊 訪問令牌類型注冊表（按照步驟中的步驟） 部分11.1），或者通過使用唯一的絕對URI作為它的名字。 使用URI名稱的類型應該僅限於供應商特定的 不常用的實現，並且是特定的 資源服務器的實現細節在哪里 用過的。 所有其他類型必須注冊。類型名稱必須符合 鍵入名稱ABNF。如果類型定義包含新的HTTP 認證方案，類型名稱應該與HTTP相同 認證方案名稱（由[ RFC2617 ]）。令牌類型 “示例”保留用於示例。 type-name = 1 * name-char name-char =“ - ”/“。” /“_”/ DIGIT / ALPHA 。 用於授權的新請求或響應參數 端點或令牌端點被定義並注冊在 OAuth參數注冊表遵循第11.2節中的過程。 參數名稱必須符合參數名稱ABNF和參數 值語法必須是明確定義的（例如，使用ABNF或引用 到現有參數的語法）。 param-name = 1 * name-char name-char =“ - ”/“。” /“_”/ DIGIT / ALPHA

 未注冊的特定於供應商的參數擴展名不是 通常適用並且特定於實施 使用它們的授權服務器的詳細信息應該 利用不太可能與供應商相關的前綴 其他注冊值（例如，以'companyname_'開頭）。  新的授權授權類型可以通過分配給他們定義 用於“grant_type”參數的唯一絕對URI。如果 擴展授權類型需要額外的令牌端點參數， 它們必須按照所述在OAuth參數注冊表中進行注冊 由第11.2節。 。 用於授權端點的新響應類型是 定義並注冊在授權端點響應類型中 按照第11.3節中的程序進行注冊。響應類型 名稱必須符合響應型ABNF。 response-type = response-name *（SP響應名稱） response-name = 1 * response-char response-char =“_”/ DIGIT / ALPHA 如果響應類型包含一個或多個空格字符（％x20），則該字符為空 被比較為空格分隔的值的列表，其中的順序為 值並不重要。只有一個值的順序可以被注冊， 其中涵蓋了同一組值的所有其他安排。 例如，響應類型“令牌代碼”由此未定義 規范。但是，擴展可以定義和注冊 “令牌代碼”響應類型。一旦注冊，相同的組合 不能注冊為“代碼令牌”，但兩個值都可以用於 表示相同的響應類型。 在協議擴展（即訪問令牌類型， 擴展參數或擴展授權類型）需要額外的 與授權碼授權錯誤一起使用的錯誤代碼 響應，隱式授予錯誤響應 ，令牌錯誤響應（或者 資源訪問錯誤響應，這樣的錯誤代碼可能是 定義。

 擴展錯誤代碼必須注冊（按照中的步驟） 如果他們與之一起使用的擴展名是 注冊的訪問令牌類型，注冊的端點參數或者 擴展授權類型。用於未注冊的擴展的錯誤代碼 可以注冊。 錯誤代碼必須符合錯誤ABNF並且應該以前綴 一個可能的識別名稱。例如，錯誤標識 對擴展參數“example”設置的無效值應該是 命名為“example_invalid”。 錯誤= 1 *錯誤 - 字符 error-char =％x20-21 /％x23-5B /％x5D-7E  本機應用程序是在設備上安裝並執行的客戶端 由資源所有者使用（即桌面應用程序，本地移動 應用）。本機應用程序需要特殊考慮 與安全性，平台功能和總體最終用戶有關 經驗。 授權端點需要客戶端之間的交互 和資源所有者的用戶代理。本地應用程序可以調用 外部用戶代理或在應用程序中嵌入用戶代理。 例如： o外部用戶代理 - 本機應用程序可以捕獲 來自授權服務器的使用重定向URI的響應 用在操作系統上注冊的方案來調用 客戶端作為處理程序，手動復制並粘貼憑證， 運行本地Web服務器，安裝用戶代理擴展或 通過提供標識服務器托管的重定向URI 資源在客戶的控制之下，這反過來又使得這些資源得以實現 對本地應用程序可用的響應。 o嵌入式用戶代理 - 本地應用程序獲取響應 通過直接與嵌入式用戶代理進行通信 監視資源加載期間發出的狀態變化，或者 訪問用戶代理的Cookie存儲。 在外部或嵌入式用戶代理之間進行選擇時，開發人員 應該考慮以下幾點： o外部用戶代理可能會提高完成率，因為 資源所有者可能已經有一個活動會話 授權服務器，無需重新進行身份驗證。它 提供了熟悉的最終用戶體驗和功能。該

 資源所有者也可能依賴用戶代理功能或擴展 以協助認證（例如，密碼管理器，雙因素 設備讀取器）。 o嵌入式用戶代理可以提供改進的可用性，因為它被刪除 需要切換上下文並打開新窗口。 o嵌入式用戶代理由於資源而構成安全挑戰 業主在沒有通行證的不明身份的窗戶中進行身份驗證 到大多數外部用戶代理中的視覺保護。一個 嵌入式用戶代理教育最終用戶信任不明身份 請求認證（使釣魚攻擊更容易 執行）。 在隱式授權類型和授權之間進行選擇時 代碼授予類型，應考慮以下內容： o使用授權代碼授權類型的本機應用程序 由於本機的原因，應該不使用客戶端憑據 應用程序無法保持客戶端證書的機密性。 o使用隱式授權類型流時，刷新令牌不是 返回，這需要重復授權過程一次 訪問令牌到期。  作為一種靈活且可擴展的框架，OAuth的安全性 考慮取決於許多因素。以下部分 為實施者提供關於這三者的安全准則
 ：web應用程序， 基於用戶代理的應用程序和本地應用程序。  授權服務器使用Web建立客戶端憑證 應用程序客戶端用於客戶端身份驗證。該 鼓勵授權服務器考慮更強大的客戶端 認證意味着不是客戶端密碼。Web應用程序客戶 務必確保客戶密碼和其他客戶的機密性 證書。

 授權服務器不得發布客戶密碼或其他 客戶端憑據本地應用程序或基於用戶代理 應用程序客戶端用於客戶端身份驗證。該 授權服務器可以發布客戶端密碼或其他憑證 用於特定安裝a。上的本機應用程序客戶端 特定設備。 當客戶端身份驗證不可行時，授權服務器 應該采用其他方式來驗證客戶的身份 - 因為 例如，通過要求注冊客戶端重定向URI 或征募資源所有者確認身份。一個有效的 重定向URI不足以驗證客戶端的身份 當請求資源所有者授權但可用於 防止在將證書交付給偽造的客戶端之后 獲取資源所有者授權。 授權服務器必須考慮安全影響 與未經認證的客戶端進行交互並采取措施進行限制 其他憑證的潛在風險（例如刷新令牌） 發給這些客戶。  惡意客戶可以模擬另一個客戶並獲得訪問權限 如果被冒充的客戶端未能或者未能保護資源 無法保留其客戶資料的機密。 每當授權服務器都必須認證客戶端 可能。如果授權服務器無法認證客戶端 由於客戶端的本質，授權服務器必須要求 注冊用於接收授權的任何重定向URI 響應和應該利用其他手段來保護資源所有者 來自這些潛在的惡意客戶。例如， 授權服務器可以讓資源所有者協助 確定客戶及其來源。 授權服務器應該強制顯式資源所有者 驗證並向資源所有者提供有關的信息 客戶端和請求的授權范圍和生命周期。它是 直至資源所有者在上下文中檢查信息 當前客戶端並授權或拒絕請求。 授權服務器不應該處理重復授權 自動請求（沒有活動的資源所有者交互） 無需認證客戶或依靠其他措施 確保重復的請求來自原始客戶端和 不是模仿者。

 訪問令牌憑證（以及任何機密訪問令牌 屬性）必須在運輸和存儲過程中保密，並且 只在授權服務器，資源服務器之間共享 訪問令牌對於以及訪問令牌所在的客戶端有效 發行。訪問令牌憑證只能使用TLS傳輸 ，服務器認證由定義 [ RFC2818 ]。 當使用隱式授權類型時，傳輸訪問令牌 在URI片段中，它可以將其暴露給未授權方。 授權服務器必須確保訪問令牌不可以 生成，修改或猜測來生成有效的訪問令牌 未授權方。 客戶端應該以最小范圍請求訪問令牌 必要。授權服務器應該采用客戶端身份 在選擇如何兌現請求的范圍和可能時考慮到 使用比請求更少的權限發布訪問令牌。 本規范不提供任何資源的方法 服務器來確保給定的訪問令牌提供給它 客戶端由授權服務器發布給該客戶端。 授權服務器可以向Web應用程序發放刷新令牌 客戶和本機應用程序客戶端 刷新令牌在運輸和存儲過程中必須保密，並且 只在授權服務器和客戶端共享 刷新令牌被發布。授權服務器必須維護 刷新令牌和它所在的客戶端之間的綁定 發行。刷新令牌只能使用TLS作為 ，服務器認證由定義 [ RFC2818 ]。 授權服務器必須驗證刷新之間的綁定 令牌和客戶端身份 認證。當客戶認證不可能時， 授權服務器應該部署其他手段來檢測刷新 令牌濫用。 例如，授權服務器可以使用刷新令牌 每次訪問都會發出一個新的刷新令牌 令牌刷新響應。之前的刷新令牌無效

 但由授權服務器保留。如果刷新令牌是 妥協並隨后被攻擊者和攻擊者使用 合法的客戶端，其中一個會呈現無效刷新 令牌，它會通知授權服務器違規。 授權服務器必須確保刷新令牌不可以 生成，修改或猜測來生成有效的刷新標記 未授權方。  授權代碼的傳輸應該通過安全的方式進行 頻道，並且客戶端應該要求使用TLS 如果URI標識網絡資源，則重定向URI。以來 授權碼通過用戶代理重定向傳輸 可能會通過用戶代理歷史記錄和HTTP進行披露 引薦標題。 授權碼作為純文本承載憑證運行，用於 驗證資源所有者是誰授予了授權 授權服務器是相同的資源所有者返回的 客戶端完成該過程。因此，如果客戶依賴 其自己的資源所有者認證的授權碼， 客戶端重定向端點必須要求使用TLS。 授權碼必須是短暫的和單次使用的。如果 授權服務器觀察多次嘗試交換一個 訪問令牌的授權碼，授權服務器 應該嘗試撤銷已根據授予的所有訪問令牌 受損的授權碼。 如果客戶端可以被認證，授權服務器必須 驗證客戶端並確保授權碼是 發給同一個客戶。  使用授權碼授權請求授權時 類型，客戶端可以通過“redirect_uri”指定重定向URI， 參數。如果攻擊者可以操縱該值 重定向URI，它可以導致授權服務器重定向 將資源所有者的用戶代理轉換為在其控制下的URI 攻擊者使用授權碼。 攻擊者可以在合法客戶端創建一個帳戶並啟動 授權流程。當攻擊者的用戶代理被發送到 授權服務器授予訪問權限，攻擊者抓獲 授權URI由合法客戶端提供並替換

 客戶端的重定向URI與URI控制下的 攻擊者。攻擊者然后欺騙受害者追蹤 操縱的鏈接授權訪問合法的客戶端。 一旦進入授權服務器，受害者就會被提示一個 正常，有效的請求代表合法和可信的客戶端， 並授權請求。受害者然后被重定向到 在受到攻擊者控制的端點上進行授權 碼。攻擊者通過發送完成授權流程 授權代碼使用原始重定向URI給客戶端 由客戶提供。客戶端交換授權碼 使用訪問令牌並將其鏈接到攻擊者的客戶端帳戶， 現在它可以訪問授權的受保護資源 受害者（通過客戶端）。 為了防止這種攻擊，授權服務器必須 確保用於獲取授權碼的重定向URI 與交換時提供的重定向URI相同 訪問令牌的授權碼。授權服務器 必須要求公共客戶，並且應該要求保密的客戶 注冊他們的重定向URI。如果提供重定向URI 在請求中，授權服務器必須對其進行驗證 注冊價值。  資源所有者密碼憑據授權類型通常用於 遺留或遷移原因。它降低了存儲的整體風險 用戶名和密碼由客戶，但並沒有消除這種需要 向客戶端公開高度特權的證書。 這種授權類型比其他授權類型具有更高的風險，因為 它維護該協議尋求避免的密碼反模式。 客戶可能會濫用密碼，或密碼可能 無意中被泄露給攻擊者（例如，通過日志文件或 客戶保存的其他記錄）。 另外，因為資源所有者無法控制 授權過程（資源所有者的參與在什么時候結束 它將其憑據交給客戶），客戶可以獲得 訪問具有比資源所期望的范圍更廣的范圍的令牌 所有者。授權服務器應考慮范圍和 通過此授予類型發放的訪問令牌的生存期。 授權服務器和客戶端應該盡量減少對該授權的使用 盡可能地鍵入和使用其他授權類型。

 訪問令牌，刷新令牌，資源所有者密碼和客戶端 憑證不得以明文傳送。授權 代碼不應以明文形式傳輸。 “狀態”和“范圍”參數不應包含敏感 客戶端或資源所有者信息以純文本格式顯示，因為它們可能是 通過不安全的頻道傳輸或不安全地存儲。  為了防止中間人攻擊，授權 服務器必須要求使用帶有服務器認證的TLS 由[ RFC2818 ]對發送給授權的任何請求進行定義 令牌端點。客戶端必須驗證授權服務器 TLS證書由[ RFC6125 ] 定義並按照其規定 服務器身份驗證的要求。 授權服務器必須防止攻擊者猜測訪問 令牌，授權碼，刷新令牌，資源所有者 密碼和客戶端憑證。 攻擊者猜測產生令牌的可能性（和其他 不打算由最終用戶處理的證書）必須小於 或等於2 ^（ - 128）且應該小於或等於2 ^（ - 160）。 授權服務器必須利用其他手段來保護 用於最終用戶使用的證書。  這種和類似協議的廣泛部署可能會導致最終用戶 變得習慣於被重定向到網站的做法 他們被要求輸入他們的密碼。如果最終用戶不是 在進入之前請仔細核實這些網站的真實性 他們的憑據，攻擊者可能會利用這一點 練習盜取資源所有者的密碼。 服務提供商應該嘗試教育最終用戶有關風險 網絡釣魚攻擊構成，並應提供簡單的機制 為最終用戶確認其網站的真實性。客戶 開發人員應該考慮它們的安全含義 與用戶代理（例如，外部的，嵌入的）交互，以及 最終用戶的能力驗證的真實性 授權服務器。

 為了降低釣魚攻擊的風險，授權服務器 必須要求在用於最終用戶的每個端點上使用TLS 相互作用。  跨站請求偽造（CSRF）是攻擊者的一種攻擊手段 導致受害最終用戶的用戶代理跟隨惡意URI （例如，作為誤導性的鏈接，圖像或者提供給用戶代理 重定向）到信任服務器（通常通過 有效會話cookie的存在）。 針對客戶端的重定向URI的CSRF攻擊允許攻擊者 注入自己的授權碼或訪問令牌，這可以 導致客戶端使用與該關聯的訪問令牌 攻擊者的受保護資源而不是受害者的（例如，保存 將受害者的銀行賬戶信息傳送給受保護的資源 由攻擊者控制）。 客戶端必須為其重定向URI實施CSRF保護。 這通常是通過要求發送給任何請求來完成的 重定向URI端點包含綁定請求的值 用戶代理的認證狀態（例如會話的散列 用於驗證用戶代理的cookie）。客戶端應該 利用“狀態”請求參數將此值傳遞給 授權服務器在進行授權請求時。 一旦從最終用戶獲得授權， 授權服務器將最終用戶的用戶代理重定向回 客戶端具有包含在“狀態”中的所需綁定值 參數。綁定值使客戶端能夠驗證 通過匹配綁定值與請求的有效性 用戶代理的身份驗證狀態。用於CSRF的綁定值 保護必須包含一個不可猜測的值，以及用戶代理的認證狀態（例如， 會話cookie，HTML5本地存儲）必須保存在一個位置 只能由客戶端和用戶代理訪問（即受到 同源政策）。 針對授權服務器授權的CSRF攻擊 端點可能導致攻擊者獲得最終用戶授權 針對惡意客戶而不涉及或警告最終用戶。 授權服務器必須為其實施CSRF保護 授權端點並確保惡意客戶端不能 在沒有意識和明確同意的情況下獲得授權 資源所有者。

 在點擊劫持攻擊中，攻擊者注冊一個合法的客戶端 然后構建一個惡意網站，在其中加載該網站 授權服務器的授權端點網頁 透明的iframe覆蓋在一組虛擬按鈕的頂部， 精心構建，直接置於重要位置 授權頁面上的按鈕。當最終用戶點擊一個 誤導可見按鈕，最終用戶實際上是點擊一個 授權頁面上的隱形按鈕（例如“授權” 按鈕）。這允許攻擊者誘騙資源所有者進入 在沒有最終用戶的知識的情況下授予其客戶端訪問權限。 為了防止這種形式的攻擊，本機應用程序應該使用 外部瀏覽器，而不是在瀏覽器中嵌入瀏覽器 應用程序在請求最終用戶授權時。對於大多數更新 瀏覽器，可以通過授權來強制避免iframe 服務器使用（非標准）“x-frame-options”標題。這個 頭可以有兩個值，“拒絕”和“sameorigin”，這將阻止 任何取景，或由不同來源的網站構圖， 分別。對於較老的瀏覽器，JavaScript框架破壞 技術可以使用，但可能不適用於所有瀏覽器。  代碼注入攻擊發生在輸入或其他外部 變量被應用程序unsanitized使用並導致 修改應用程序邏輯。這可能允許攻擊者 訪問應用程序設備或其數據，導致拒絕 服務或引入各種各樣的惡意副作用。 授權服務器和客戶端必須清理（並在何時驗證） 可能）收到的任何價值 - 特別是價值 “狀態”和“redirect_uri”參數。 授權服務器，授權端點和客戶端 重定向端點可能配置不正確，並且操作為打開 轉向器。開放重定向器是使用參數to的端點 自動將用戶代理重定向到由指定的位置 參數值沒有任何驗證。 開放重定向器可用於網絡釣魚攻擊或攻擊者 讓最終用戶通過使用URI權限訪問惡意網站 一個熟悉且受信任的目的地組件。另外，如果 授權服務器允許客戶端只注冊部分 重定向URI，攻擊者可以使用由其運行的開放重定向器

 客戶端構造一個重定向的URI將通過 授權服務器驗證，但會發送授權碼 或者在攻擊者的控制下將令牌存取到端點。 對於使用隱式流程的公共客戶，本規范沒有 為客戶端提供任何方法來確定訪問哪個客戶端 令牌被發給。 資源所有者可能願意通過委托來訪問資源 授予訪問令牌給攻擊者的惡意客戶端。這可能 是由於網絡釣魚或其他借口。攻擊者也可能偷盜 通過一些其他機制的令牌。攻擊者然后可能會嘗試 通過向a提供訪問令牌來模擬資源所有者 合法的公共客戶。 在隱式流（response_type = token）中，攻擊者可以很容易地 在授權服務器的響應中切換令牌， 用先前發放給該用戶的令牌取代真正的訪問令牌 攻擊者。 服務器與依賴於的本地應用程序進行通信 在返回通道中傳遞訪問令牌以標識用戶 客戶端可能會被攻擊者創建一個類似的攻擊 妥協的應用程序可以注入任意被盜的訪問 令牌。 任何假定只有資源的公共客戶 所有者可以為資源提供有效的訪問令牌 容易受到這種類型的攻擊。 這種類型的攻擊可能會暴露有關資源所有者的信息 在攻擊者的合法客戶端（惡意客戶端）。這個 也將允許攻擊者在合法的地方執行操作 客戶端的權限與最初的資源所有者相同 授予訪問令牌或授權碼。 為客戶驗證資源所有者不在此范圍內 規范。任何使用授權過程的規范 作為委托給客戶的最終用戶認證的一種形式（例如， 第三方登錄服務）禁止不使用隱式流 額外的安全機制，可以讓客戶 確定訪問令牌是否為其使用而發布（例如，受眾 - 限制訪問令牌）。

 該規范建立了OAuth訪問令牌類型注冊表。 訪問令牌類型使用規格要求進行注冊 （[ RFC5226 ]）在一個為期兩周的審查期后 oauth-ext-review@ietf.org郵件列表，根據一個或多個的建議 指定專家。但是，允許分配值 在公布之前，指定專家可以批准 一旦他們滿意這樣的規范將會注冊 被出版。 注冊請求必須發送到oauth-ext-review@ietf.org 郵件列表進行審查和評論，並附有適當的主題 （例如，“請求訪問令牌類型：示例”）。 在審查期內，指定專家也可以 批准或拒絕注冊請求，傳達此決定 到審核名單和IANA。否認應包含解釋 以及如果適用的話，關於如何提出請求的建議 成功的。 IANA只能接受來自指定專家的注冊表更新， 並且應該將所有的注冊請求指引到評論郵件 名單。  HTTP認證方案： HTTP身份驗證方案名稱（如果有）用於 使用訪問令牌對受保護的資源請求進行身份驗證 這個類型。 更改控制器： 對於標准跟蹤RFC，請注明“IETF”。對於其他人，請給出名稱 的責任方。其他細節（例如，郵政地址， 電子郵件地址，主頁URI）也可以包括在內。

 規格文件： 參考指定參數的文檔， 最好包括一個可以用來檢索副本的URI 文件）。相關部分的說明也可以 被包括但不是必需的。 該規范建立了OAuth參數注冊表。 包含在授權端點中的其他參數 請求，授權端點響應，令牌端點 請求或令牌端點響應是使用a注冊的 規范要求（[ RFC5226 ]）在兩周的審查期后 oauth-ext-review@ietf.org郵件列表，根據一個或多個人的建議 更多指定專家。但是，允許分配 在發布之前，指定專家可以批准 一旦他們滿意這樣的規范將會注冊 被出版。 注冊請求必須發送到oauth-ext-review@ietf.org 郵件列表進行審查和評論，並附有適當的主題 （例如，“請求參數：示例”）。 在審查期內，指定專家也可以 批准或拒絕注冊請求，傳達此決定 到審核名單和IANA。否認應包含解釋 以及如果適用的話，關於如何提出請求的建議 成功的。 IANA只能接受來自指定專家的注冊表更新， 並且應該將所有的注冊請求指引到評論郵件 名單。 。 參數名稱： 請求的名稱（例如“示例”）。 參數使用位置： 可以使用參數的位置。可能的 位置是授權請求，授權響應，令牌 請求或令牌響應。 更改控制器： 對於標准跟蹤RFC，請注明“IETF”。對於其他人，請給出名稱 的責任方。其他細節（例如，郵政地址， 電子郵件地址，主頁URI）也可以包括在內。

 規格文件： 參考指定參數的文檔， 最好包括一個可以用來檢索副本的URI 文件）。相關部分的說明也可以 被包括但不是必需的。 OAuth參數注冊表的初始內容是： o參數名稱：client_id o參數使用位置：授權請求，令牌請求 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：client_secret o參數使用位置：令牌請求 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：response_type o參數使用位置：授權請求 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：redirect_uri o參數使用位置：授權請求，令牌請求 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：范圍 o參數使用位置：授權請求，授權 響應，令牌請求，令牌響應 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：狀態 o參數使用位置：授權請求，授權 響應 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：代碼 o參數使用位置：授權響應，令牌請求 o更改控制器：IETF o規范文件：RFC 6749

 o參數名稱：error_description o參數使用位置：授權響應，令牌響應 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：error_uri o參數使用位置：授權響應，令牌響應 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：grant_type o參數使用位置：令牌請求 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：access_token o參數使用位置：授權響應，令牌響應 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：token_type o參數使用位置：授權響應，令牌響應 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：expires_in o參數使用位置：授權響應，令牌響應 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：用戶名 o參數使用位置：令牌請求 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：密碼 o參數使用位置：令牌請求 o更改控制器：IETF o規范文件：RFC 6749 o參數名稱：refresh_token o參數使用位置：令牌請求，令牌響應 o更改控制器：IETF o規范文件：RFC 6749

 該規范建立了OAuth授權端點 響應類型注冊表。 用於授權端點的其他響應類型是在兩周后 注冊了規范要求（[ RFC5226 ]） 審查期間在oauth-ext-review@ietf.org郵件列表上，在 一名或多名指定專家的建議。但是，允許的 在出版前分配價值，指定專家（S） 一旦他們滿意這樣的情況，可以批准注冊 規范將被公布。 注冊請求必須發送到oauth-ext-review@ietf.org 郵件列表進行審查和評論，並附有適當的主題 （例如，“請求響應類型：示例”）。 在審查期內，指定專家也可以 批准或拒絕注冊請求，傳達此決定 到審核名單和IANA。否認應包含解釋 以及如果適用的話，關於如何提出請求的建議 成功的。 IANA只能接受來自指定專家的注冊表更新， 並且應該將所有的注冊請求指引到評論郵件 名單。 響應類型名稱： 請求的名稱（例如“示例”）。 更改控制器： 對於標准跟蹤RFC，請注明“IETF”。對於其他人，請給出名稱 的責任方。其他細節（例如，郵政地址， 電子郵件地址，主頁URI）也可以包括在內。 規格文件： 參考指定類型的文檔，最好 包括一個可用於檢索副本的URI 文件（多個）。相關部分的說明也可能是 包括但不是必需的。

 OAuth授權端點響應類型注冊表的初始 內容是： o響應類型名稱：代碼 o更改控制器：IETF o規范文件：RFC 6749 o響應類型名稱：令牌 o更改控制器：IETF o規范文件：RFC 6749 該規范建立了OAuth擴展錯誤注冊表。 與其他協議擴展一起使用的其他錯誤代碼 （即，擴展授權類型，訪問令牌類型或擴展 參數）以需要規格（[ RFC5226 ]）注冊 在oauth-ext-review@ietf.org進行為期兩周的審查期后 郵寄名單，根據一名或多名指定專家的建議。 但是，為了在發布前允許分配值， 指定專家可以一旦批准注冊 滿意這樣的規范將被公布。 注冊請求必須發送到oauth-ext-review@ietf.org 郵件列表進行審查和評論，並附有適當的主題 （例如，“請求錯誤代碼：示例”）。 在審查期內，指定專家也可以 批准或拒絕注冊請求，傳達此決定 到審核名單和IANA。否認應包含解釋 以及如果適用的話，關於如何提出請求的建議 成功的。 IANA只能接受來自指定專家的注冊表更新， 並且應該將所有的注冊請求指引到評論郵件 名單

 相關協議擴展： 擴展授權類型的名稱，訪問令牌類型或 與錯誤代碼結合使用的擴展參數 用。 更改控制器： 對於標准跟蹤RFC，請注明“IETF”。對於其他人，請給出名稱 的責任方。其他細節（例如，郵政地址， 電子郵件地址，主頁URI）也可以包括在內。 規格文件： 參考指定錯誤代碼的文檔， 最好包括一個可以用來檢索副本的URI 文件）。相關部分的說明也可以 被包括但不是必需的。