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

1. 什麼是REST

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格式的表述形式:

　

　假如github也可以支持xml格式的表述格式，那麼結果就是這樣的:

　

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

在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表述資源的結果：

　　

2. 4 資源的連接

咱們知道REST是使用標準的HTTP方法來操做資源的，但僅僅所以就理解成帶CURD的Web數據庫架構就太過於簡單了。

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

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

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

下面展現的是github獲取某個組織下的項目列表的請求，能夠看到在響應頭裏邊增長Link頭告訴客戶端怎麼訪問下一頁和最後一頁的記錄。 而在響應體裏邊，用url來連接項目全部者和項目地址。

　　又例以下面這個例子，建立訂單後經過連接引導客戶端如何去付款。

上面的例子展現瞭如何使用超媒體來加強資源的連通性。不少人在設計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

3、什麼是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 文件）。相關部分的說明也能夠 被包括但不是必需的。