當(dāng)前位置：首頁 > 人文社科 > 生活经验 >内容正文

生活经验

从协议入手，剖析OAuth2.0(译 RFC 6749)

發(fā)布時(shí)間：2023/11/27 生活经验 43 豆豆

生活随笔收集整理的這篇文章主要介紹了从协议入手，剖析OAuth2.0(译 RFC 6749) 小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

1、介紹

? ? ??https://tools.ietf.org/html/rfc6749??

? ? ? 傳統(tǒng)的client-server授權(quán)模型，客戶端通過使用憑證（通常的用戶名和明文密碼）訪問服務(wù)端受保護(hù)的資源，為了能夠讓第三方應(yīng)用程序訪問受保護(hù)的資源，需要將憑證共享給第三方。

這就產(chǎn)生了一些問題和限制：

為了以后能夠持續(xù)訪問，第三方應(yīng)用程序可能會(huì)存儲憑證（用戶名、密碼）。
盡管密碼本身存在安全弱點(diǎn)，但服務(wù)器必須支持密碼驗(yàn)證。
由于無法限制受保護(hù)資源的訪問粒度和期限，第三方應(yīng)用程序獲得了對受保護(hù)資源的廣泛訪問。
除了修改密碼外，無法對單個(gè)第三方或者所有第三方吊銷憑證。

? ? OAuth通過引入一個(gè)授權(quán)層，并分離客戶端和資源擁有者成不同的角色來解決這個(gè)問題。在OAuth中，通過發(fā)行不同的訪問令牌（包括資源訪問范圍、生命周期、其他訪問屬性），而不是資源本身，來限制第三方應(yīng)用程序訪問受保護(hù)資源（資源擁有者保護(hù)并宿主在資源服務(wù)器）的粒度和期限，而不是直接把憑證（用戶名和密碼）提供給客戶端。

? ? 例如：一個(gè)終端用戶（資源擁有者）可以授權(quán)一個(gè)打印服務(wù)（客戶端）來訪問宿主在圖片共享服務(wù)器（資源服務(wù)器）上的受保護(hù)的圖片（資源），而不用共享憑證（用戶名和密碼）給打印服務(wù)（客戶端）。

1.1 角色

在OAuth中定義了4中角色：

資源所有者（resource owner）

能夠?qū)κ鼙Ｗo(hù)資源授予訪問權(quán)的實(shí)體，當(dāng)資源的所有者是人時(shí)，指的就是我們的終端用戶。?

? ? ? ??資源服務(wù)（resource server）

? ? ? ?宿主受保護(hù)的資源。能夠接受和響應(yīng)使用訪問令牌（access tokens）對受保護(hù)資源的請求。

? ? ? ? 客戶端（client）

? ? ? ?對受保護(hù)資源發(fā)起請求的應(yīng)用程序。可能是一個(gè)服務(wù)、桌面應(yīng)用程序、或者其他設(shè)備。

? ? ? ??授權(quán)服務(wù)（authorization server）

? ? ? ?成功認(rèn)證資源所有者和獲得授權(quán)后，發(fā)行訪問令牌給客戶端。

授權(quán)服務(wù)和資源服務(wù)之間的交互不在超過該規(guī)范，授權(quán)服務(wù)和資源服務(wù)可能是同一個(gè)服務(wù)，也可能是不同的服務(wù)。單個(gè)授權(quán)服務(wù)器應(yīng)該可以發(fā)行由多個(gè)資源服務(wù)器接受的訪問令牌。

1.2 協(xié)議流程

     +--------+                               +---------------+|        |--(A)- Authorization Request ->|   Resource    ||        |                               |     Owner     ||        |<-(B)-- Authorization Grant ---|               ||        |                               +---------------+|        ||        |                               +---------------+|        |--(C)-- Authorization Grant -->| Authorization || Client |                               |     Server    ||        |<-(D)----- Access Token -------|               ||        |                               +---------------+|        ||        |                               +---------------+|        |--(E)----- Access Token ------>|    Resource   ||        |                               |     Server    ||        |<-(F)--- Protected Resource ---|               |+--------+                               +---------------+

    (A) 客戶端向資源所有者請求授權(quán)，這時(shí)授權(quán)請求可能直接提交給資源所有者，也可能提交給授權(quán)服務(wù)（扮演一個(gè)授權(quán)終端）。

    (B) 客戶端獲得一個(gè)資源所有者授權(quán)許可的憑證。授權(quán)許可類型可以使用規(guī)范中定義的4中類型，也可以自定類型（注意：授權(quán)服務(wù)需要支持自定義授權(quán)許可類型）。

    (C) 客戶端通過提交授權(quán)許可憑證給授權(quán)服務(wù)，請求訪問令牌。

    (d) 授權(quán)服務(wù)認(rèn)證客戶端并驗(yàn)證授權(quán)許可憑證，頒發(fā)訪問令牌。

    (E) 客戶端通過提交已認(rèn)證的訪問令牌，請求受保護(hù)的資源。

    (F) 資源服務(wù)驗(yàn)證訪問令牌，如果有效，響應(yīng)請求。
注意：客戶端獲取獲取授權(quán)許可憑證的首選方法，就是使用授權(quán)服務(wù)作為一個(gè)中介。

1.3 授權(quán)許可

代表資源所有者授權(quán)的一個(gè)憑據(jù)，可以用獲取訪問令牌；OAuth2.0 協(xié)議定義了4中授權(quán)許可類型：授權(quán)碼模式、隱性模式、資源所有者密碼憑證、客戶端憑證。也可以自定義擴(kuò)展的授權(quán)許可類型。

1.3.1?授權(quán)碼模式（Authorization Code）

? ? ? ? 授權(quán)碼通過一個(gè)授權(quán)服務(wù)器獲得，授權(quán)服務(wù)在客戶端和資源所有者之間扮演一個(gè)中介。客戶端不是直接從資源所有者請求授權(quán)，而是將資源所有者指向授權(quán)服務(wù)器，然后授權(quán)服務(wù)器在將資源所有者引導(dǎo)到客戶端，并攜帶授權(quán)碼。在重定向資源服務(wù)器到客戶端之前，授權(quán)服務(wù)器認(rèn)證資源所有者并獲得授權(quán)。注意授權(quán)服務(wù)器僅僅認(rèn)證資源所有者，并不會(huì)共享憑證給客戶端。

? ? ? ?授權(quán)碼提供了一些重要的安全好處，例如認(rèn)證客戶端，也可以用于直接獲取令牌，而不再需要經(jīng)過資源所有者，也可以暴露給其他人，包括資源所有者。

1.3.2?隱性模式（Implicit）

? ? ? ?隱性模式是授權(quán)碼模式的簡化版，使用一個(gè)腳本語言（例如：JavaScript）優(yōu)化了客戶端的實(shí)現(xiàn)。在隱性模式中，資源所有者授權(quán)后，并不會(huì)為客戶端頒發(fā)授權(quán)碼，而是直接頒發(fā)一個(gè)訪問令牌。因?yàn)椴]有頒發(fā)中間憑證（例如：授權(quán)碼），授權(quán)許可類型是隱性的，故稱之為隱性模式。

? ? ? ?在隱式授權(quán)流中發(fā)布訪問令牌時(shí)，授權(quán)服務(wù)器不驗(yàn)證客戶端。在某些情況下，客戶端標(biāo)識可以通過傳遞訪問令牌給客戶端的重定向URI來識別，訪問令牌能夠暴露給資源所有者和其他資源所有者訪問的應(yīng)用程序。隱性模式提高了某些客戶端的響應(yīng)速度和效率（例如：作為瀏覽器應(yīng)用程序?qū)崿F(xiàn)的客戶端）,因?yàn)樗鼫p少了獲取訪問令牌所需的往返次數(shù)。但是當(dāng)安全性要求很高的場景下，這種模式需要權(quán)衡，特別是當(dāng)授權(quán)碼模式可用的情況下。

1.3.3?客戶端的驗(yàn)證授權(quán)模式（Resource Owner Password Credentials）

? ? ? ?客戶端的驗(yàn)證授權(quán)（即用戶名和密碼）可以直接作為授權(quán)許可，來獲得訪問令牌。只有當(dāng)資源所有者充分信任（例如：客戶端是整個(gè)系統(tǒng)的一部分，或者是特權(quán)應(yīng)用程序，或者其他授權(quán)許可不可用時(shí)）客戶端的情況下，才使用該模式。盡管這種授權(quán)許可類型要求客戶端直接訪問資源所有者的憑據(jù)，但資源所有者憑證只能用于單個(gè)請求，來交換訪問令牌。通過使用長壽命的訪問令牌或者刷新令牌，該模式消除了客戶端存儲資源所有者憑證（以備將來使用）的需求。

1.3.4?客戶端憑證模式（Client Credentials）

? ? ? ?當(dāng)授權(quán)范圍僅限于受客戶端控制的受保護(hù)資源時(shí)，客戶端憑據(jù)可以用作授權(quán)許可。通常當(dāng)客戶以自己的名義行事時(shí)（此時(shí)，客戶端也是一個(gè)資源所有者），客戶端許可會(huì)被使用。

1.4?訪問令牌（Access Token）

? ? ? ?訪問令牌是用于訪問受保護(hù)資源的憑證。訪問令牌是表示向客戶機(jī)頒發(fā)的授權(quán)的字符串，該字符串通常對客戶端不透明。該令牌帶有特定的范圍（控制資源訪問粒度）和持續(xù)時(shí)間，由資源所有者授權(quán)許可，資源服務(wù)器和授權(quán)服務(wù)器強(qiáng)行執(zhí)行。令牌可能表示用于檢索授權(quán)信息的標(biāo)識符，也可能以可驗(yàn)證方式自包含授權(quán)信息（一個(gè)訪問令牌字符串由一些數(shù)據(jù)和一個(gè)簽名信息組成）。

? ? ? ?訪問令牌是一個(gè)抽象的層，里面放置著各種各樣資源服務(wù)器能夠理解的構(gòu)造信息（例如：資源的訪問范圍、持續(xù)時(shí)間等等）。通過抽象，也使訪問令牌的頒發(fā)不獲得授權(quán)許可更受限制，同時(shí)也消除了資源服務(wù)器需要理解多種認(rèn)證方法的需要。

? ? ? ?基于資源服務(wù)器安全（例如：加密屬性）的需求，訪問令牌可能有不同的格式、結(jié)構(gòu)、使用方法。

1.5 刷新令牌（Refresh Token）

? ? ? ??刷新令牌是一個(gè)用于獲取訪問令牌的憑證。刷新令牌由授權(quán)服務(wù)器頒發(fā)給客戶端，如果當(dāng)前的訪問令牌無效或者過期時(shí)，獲取一個(gè)新的訪問令牌；或者強(qiáng)制再請求一個(gè)訪問令牌（可能相同或更窄范圍的訪問令牌）。與資源所有者相比，訪問令牌有更短的生命周期和更少的權(quán)限。對于授權(quán)服務(wù)器而言，頒發(fā)一個(gè)刷新令牌是可選的，但是當(dāng)要頒發(fā)刷新令牌時(shí)，一般情況下，刷新令牌是伴隨著訪問令牌一起頒發(fā)的。

? ? ? ? 刷新令牌代表資源所有者對客戶端給予授權(quán)許可的字符串，通過對客戶端不透明。令牌表示用于檢索授權(quán)信息的標(biāo)識符。與訪問令牌不同，刷新令牌僅用于授權(quán)服務(wù)器，且從不發(fā)送到資源服務(wù)器。

  +--------+                                           +---------------+|        |--(A)------- Authorization Grant --------->|               ||        |                                           |               ||        |<-(B)----------- Access Token -------------|               ||        |               & Refresh Token             |               ||        |                                           |               ||        |                            +----------+   |               ||        |--(C)---- Access Token ---->|          |   |               ||        |                            |          |   |               ||        |<-(D)- Protected Resource --| Resource |   | Authorization || Client |                            |  Server  |   |     Server    ||        |--(E)---- Access Token ---->|          |   |               ||        |                            |          |   |               ||        |<-(F)- Invalid Token Error -|          |   |               ||        |                            +----------+   |               ||        |                                           |               ||        |--(G)----------- Refresh Token ----------->|               ||        |                                           |               ||        |<-(H)----------- Access Token -------------|               |+--------+           & Optional Refresh Token        +---------------+圖 2: 刷新一個(gè)過期的訪問令牌

 (A) 客戶端請求授權(quán)服務(wù)器的認(rèn)證，并提交授權(quán)許可。

 (B) 授權(quán)服務(wù)器認(rèn)證客戶端并驗(yàn)證授權(quán)許可后，頒發(fā)訪問令牌和刷新令牌。

 (C) 客戶端向資源服務(wù)器發(fā)出受保護(hù)的資源請求，并提交訪問令牌。

 (D) 資源服務(wù)器驗(yàn)證訪問令牌后，把受保護(hù)的資源響應(yīng)給客戶端。

 (E) 步驟（C）和（D）重復(fù)，直到訪問令牌過期。如果客戶端知道訪問令牌過期，就會(huì)跳到步驟（G）。否則，它將創(chuàng)建另一個(gè)受保護(hù)的資源請求。

 (F) 由于訪問令牌無效，資源服務(wù)器返回一個(gè)無效的令牌錯(cuò)誤。

 (G) 客戶端請求一個(gè)新的訪問令牌，并提交刷新令牌。客戶端身份驗(yàn)證需求基于客戶機(jī)類型和授權(quán)服務(wù)器策略。

 (H) 授權(quán)服務(wù)器認(rèn)證客戶端并驗(yàn)證刷新令牌后，如果有效，頒發(fā)一個(gè)新的訪問令牌（此時(shí)，是否頒發(fā)一個(gè)新的刷新令牌是可選的）。

1.6 TLS版本（TLS Version）

? ? ? ?基于廣泛部署和已知的安全漏洞，TLS版本都是隨著時(shí)間變化而變化的。TLS版本1是最廣泛部署的版本，將提供最廣泛的互操作性。具體實(shí)現(xiàn)還可以支持滿足其安全要求的附加傳輸層安全機(jī)制。

1.7 HTTP重定向（HTTP Redirections）

? ? ? ?該規(guī)范充分利用了Http重定向，客戶端和授權(quán)服務(wù)器將資源所有者用戶代理重定向到另外的目的地。雖然規(guī)范中的示例顯示了HTTP 302狀態(tài)代碼的使用，但是允許用戶代理運(yùn)用任何其他方法來完成此重定向，并被認(rèn)為是實(shí)現(xiàn)細(xì)節(jié)。

1.8?互操作性（Interoperability）

? ? ? ?OAuth 2提供了一個(gè)明確的安全特性豐富的授權(quán)框架。然而，作為一個(gè)豐富且高度可擴(kuò)展的框架，有許多可選組件，這一規(guī)范本身可能會(huì)產(chǎn)生廣泛的非互操作性實(shí)現(xiàn)。此外，該規(guī)范還提供部分必需的部分或完全未定義的組件（例如，客戶端注冊、授權(quán)服務(wù)器功能、端點(diǎn)發(fā)現(xiàn)）。沒有這些組件，針對一個(gè)特定的授權(quán)服務(wù)器，資源服務(wù)器的互操作，客戶端必須手動(dòng)配置。這個(gè)框架的設(shè)計(jì)帶有明確的期望，未來的工作將定義實(shí)現(xiàn)完整Web規(guī)模互操作性所必需的規(guī)范配置文件和擴(kuò)展。

1.9?符號約定（Notational Conventions）

? ? ? ?該協(xié)議中的關(guān)鍵詞?"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"在?[RFC2119] 中被詳細(xì)的描述。該規(guī)范使用[RFC5234]中的?the Augmented Backus-Naur Form (ABNF)符號規(guī)范。此外，規(guī)則的URI引用被包含在“統(tǒng)一資源標(biāo)識符（URI）：通用語法”[ rfc3986 ]中。某些安全相關(guān)的術(shù)語被定義在[RFC4949]中，這些術(shù)語包括但不限于?"attack", "authentication", "authorization", "certificate","confidentiality", "credential", "encryption", "identity", "sign","signature", "trust", "validate", and "verify"。除非另有說明，所有協(xié)議參數(shù)名稱和值都是區(qū)分大小寫的。

2、客戶端注冊（Client Registration）

? ? ? ?在啟動(dòng)協(xié)議之前，客戶端使用授權(quán)服務(wù)器進(jìn)行注冊。客戶端通過授權(quán)服務(wù)器注冊的方式超過了該協(xié)議的范圍，但是一般都是終端用戶通過一個(gè)HTML表單提交注冊。客戶端注冊并不需要客戶端和授權(quán)服務(wù)器的直接交互，只要授權(quán)服務(wù)器支持，可以使用各種各樣的放肆進(jìn)行注冊并獲取已注冊客戶端的屬性。例如：可以使用一個(gè)自發(fā)布或者第三方發(fā)布的聲明（assertion）或者授權(quán)服務(wù)器通過一個(gè)信任的通道來進(jìn)行客戶端的發(fā)現(xiàn)。

? ? ? ?當(dāng)注冊一個(gè)客戶端時(shí)，客戶端開發(fā)人員應(yīng)該：

指定客戶端類型
提供客戶端重定向的URI
包括授權(quán)服務(wù)器所要求的任何其他信息（例如，應(yīng)用程序名稱，網(wǎng)站，描述，Logo圖像，服務(wù)條款等等）。

2.1 客戶端類型（Client Types）

? ? ? ? ? ? ? 基于客戶端和授權(quán)服務(wù)器，安全認(rèn)證的能力（例如：客戶憑證的保密性），OAuth定義了兩種類型的客戶端。

? ? ? ? ? ? ?保密類型（confidential）

? ? ? ? ? ? ?能夠維護(hù)其憑證的保密性的客戶端（例如：客戶端在一個(gè)安全的服務(wù)器上，客戶端的訪問受到限制），能夠通過其他方式來保證客戶端認(rèn)證的安全性。

? ? ? ? ? ? ?公開類型（pulic）

? ? ? ? ? ???不能夠維護(hù)其憑證的保密性的客戶端（例如：在資源所有者的設(shè)備上執(zhí)行客戶端，如已安裝的本機(jī)應(yīng)用程序或基于Web瀏覽器的應(yīng)用程序），不能夠通過其他方式來保證客戶端認(rèn)證的安全性。

? ? ? ? ? ? ?客戶機(jī)類型指定是基于授權(quán)服務(wù)器對安全認(rèn)證的定義及其可接受的客戶端證書的暴露級別。授權(quán)服務(wù)器不應(yīng)該對客戶端類型做出假設(shè)。客戶機(jī)可以實(shí)現(xiàn)為一組分布式組件，每個(gè)組件具有不同的客戶機(jī)類型和安全上下文（例如，一個(gè)分布式客戶端既有基于服務(wù)器的機(jī)密組件，又有基于公共瀏覽器的組件）；如果傳統(tǒng)授權(quán)服務(wù)器不能夠?qū)@樣的客戶端提供支持或者注冊引導(dǎo)，客戶應(yīng)將每個(gè)組件注冊為單獨(dú)的客戶機(jī)。

? ? ? ? ? ? ?本規(guī)范是圍繞以下客戶端配置文件設(shè)計(jì)的：

? ? ? ? ? ? ?web 應(yīng)用程序（web application）

? ? ? ? ? ? ?Web應(yīng)用程序是在Web服務(wù)器上運(yùn)行的機(jī)密客戶端。資源所有者通過在其使用的設(shè)備上的通過用戶代理（瀏覽器）中呈現(xiàn)的HTML用戶界面訪問客戶端。客戶端憑據(jù)以及向客戶機(jī)發(fā)出的任何訪問令牌都存儲在Web服務(wù)器上，不會(huì)被資源所有者暴露或訪問。??

? ? ? ? ? ? ?基于用戶代理的應(yīng)用程序（user-agent-based application）

? ? ? ? ? ? ?基于用戶代理的應(yīng)用程序是一個(gè)公共客戶端，其中客戶端代碼從Web服務(wù)器下載并在由資源所有者所使用的設(shè)備的用戶代理內(nèi)執(zhí)行。?所以，對于資源所有者，協(xié)議數(shù)據(jù)和憑證可以很容易獲得。由于這些應(yīng)用程序駐留在用戶代理中，所以在請求授權(quán)時(shí)可以無縫地使用用戶代理功能。

? ? ? ? ? ? ?本地應(yīng)用程序（native application）

? ? ? ? ? ? ?本機(jī)應(yīng)用程序是安裝在資源所有者使用的設(shè)備上并執(zhí)行的公共客戶機(jī)。對于資源所有者，協(xié)議數(shù)據(jù)和證書是可得到的。假設(shè)可以提取應(yīng)用程序中包含的任何客戶端身份驗(yàn)證憑據(jù)。另一方面，動(dòng)態(tài)發(fā)布的憑據(jù)（如訪問令牌或刷新令牌）可以收到可接受的保護(hù)級別。至少，這些憑據(jù)被保護(hù)免受應(yīng)用程序可能交互的惡意服務(wù)器的保護(hù)。某些情況下，這些應(yīng)用程序也會(huì)受到保護(hù)免受駐留在同一設(shè)備的其他應(yīng)用程序的干擾。

? ? ?2.2 客戶端標(biāo)識（Client?Identifier）

? ? ? ? ? ?授權(quán)服務(wù)器向注冊客戶端頒發(fā)客戶端標(biāo)識符------表示客戶端提供的注冊信息的唯一字符串。客戶機(jī)標(biāo)識符不是秘密，它暴露給資源所有者，不能單獨(dú)用于客戶端身份驗(yàn)證。

客戶端標(biāo)識符對授權(quán)服務(wù)器是唯一的。

? ? ? ? ? ?客戶標(biāo)識符字符串大小該規(guī)范未定義。客戶機(jī)應(yīng)該避免對標(biāo)識符大小做出假設(shè)。授權(quán)服務(wù)器應(yīng)該記錄它所頒發(fā)的任何標(biāo)識符的大小。

? ? ?2.3 客戶端認(rèn)證（Client Authentication）

? ? ? ? ? ?如果客戶機(jī)類型是機(jī)密的，客戶機(jī)和授權(quán)服務(wù)器建立適合于授權(quán)服務(wù)器的安全需求的客戶端身份驗(yàn)證方法。授權(quán)服務(wù)器可以接受滿足其安全要求的任何形式的客戶端身份驗(yàn)證。機(jī)密客戶機(jī)通常發(fā)布（或建立）一組客戶端證書，用于與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證（例如，密碼、公鑰/私鑰對）。授權(quán)服務(wù)器可以和公共客戶端建立客戶端認(rèn)證方法。但是，授權(quán)服務(wù)器不能依賴公共客戶端身份驗(yàn)證，以識別客戶機(jī)。在每個(gè)請求中，客戶端不能使用多個(gè)身份驗(yàn)證方法。

? ? ? ? ? ? ?2.3.1?客戶端密碼（Client Password）

? ? ? ? ? ? ? ? ? ? ?擁有客戶端密碼的客戶機(jī)可以使用HTTP基本身份驗(yàn)證方案和授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證。客戶端標(biāo)識使用"application/x-www-form-urlencoded"編碼算法進(jìn)行編碼，編碼值用作用戶名。客戶端密碼使用相同的算法進(jìn)行編碼，并用作密碼。授權(quán)服務(wù)器必須支持HTTP基本身份驗(yàn)證方案，以驗(yàn)證客戶端密碼并頒發(fā)密碼。

? ? ? ? ? ? ? ? ? ? ?例如：授權(quán) Basic?czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3，還有一種可選的方案就是，在請求頭中包含兩個(gè)參數(shù)（client_id和client_secret），這種方案一般不推薦，除非客戶端不能夠使用?HTTP Basic authentication scheme （或者其他的基于密碼的HTTP authentication scheme）。參數(shù)只能在請求體中傳輸，不能包含在請求URI中。

? ? ? ? ? ? ?2.3.1?其他認(rèn)證方法（Other Authentication Methods）

? ? ? ? ? ? ? ? ? ? ?授權(quán)服務(wù)器可以支持符合其安全要求的任何合適的HTTP認(rèn)證方案。在使用其他身份驗(yàn)證方法時(shí)，授權(quán)服務(wù)器必須定義客戶端標(biāo)識符（注冊記錄）和身份驗(yàn)證方案之間的映射。

? ? ?2.4?未注冊的客戶端（Unregistered Clients）

? ? ? ? ? ? ? 該規(guī)范沒有包含未注冊的客戶端的使用。這種客戶機(jī)的使用超出了本規(guī)范的范圍，需要對其互操作性影響進(jìn)行額外的安全性分析和審查。

3、協(xié)議的端點(diǎn)（Protocol Endpoints）

? ? ??授權(quán)處理利用兩個(gè)授權(quán)服務(wù)器終結(jié)點(diǎn)：

授權(quán)端點(diǎn)

? ? ? ? ??客戶端通過用戶代理重定向到該端點(diǎn)獲得資源所有者的授權(quán)。

令牌端點(diǎn)

? ? ? ? ? 客戶機(jī)用來交換訪問令牌的授權(quán)許可，通常具有客戶端身份驗(yàn)證。

重定向端點(diǎn)

? ? ? ? ? 授權(quán)服務(wù)器用于通過資源所有者用戶代理將包含授權(quán)憑證的響應(yīng)返回給客戶端。

? ? ? 并不是每一個(gè)授權(quán)許可類型都會(huì)使用這些終結(jié)點(diǎn)；當(dāng)然擴(kuò)展的授權(quán)許可類型可以定義自己的終結(jié)點(diǎn)。

? ? 3.1 授權(quán)端點(diǎn)（Authorization Endpoint）

? ? ? ? ? ? ? 授權(quán)終結(jié)點(diǎn)與資源所有者交互獲取一個(gè)授權(quán)許可。首先授權(quán)服務(wù)器必須審核資源所有者的身份信息（授權(quán)服務(wù)器采用什么方式認(rèn)證資源所有者的身份（例如：用戶名、密碼、會(huì)話Cookie），超出了本規(guī)范的訪問）。

? ? ? ? ? ? ? 授權(quán)URI可能包含?"application/x-www-form-urlencoded"? 格式的必須的查詢組件（query parameters）。端點(diǎn)URI不能包含碎片組件（fragment component）。

? ? ? ? ? ? ??由于對授權(quán)端點(diǎn)的請求，導(dǎo)致用戶身份驗(yàn)證和明文證書的傳輸。當(dāng)發(fā)送請求到授權(quán)端點(diǎn)時(shí)，授權(quán)服務(wù)器必須要求使用TLS。授權(quán)服務(wù)器必須支持“Get”方法，也可以支持“Post”方法。

? ? ? ? ? ? ? 發(fā)送請求時(shí)，沒有值的參數(shù)會(huì)被省略。授權(quán)服務(wù)器必須忽略無法識別的請求參數(shù)。請求和響應(yīng)參數(shù)不應(yīng)包含超過一次。

? ? 3.1.1?響應(yīng)類型（Response Type）

? ? ? ? ? ? ? 授權(quán)終結(jié)點(diǎn)被授權(quán)碼模式和隱式模式使用。

? ? ? ? ? ? ? 客戶端通過下列參數(shù)來通知授權(quán)服務(wù)器期望建立的授權(quán)許可類型流：

? ? ? ? ? ? ??response_type：必須。授權(quán)碼模式時(shí)，該值必須為“code”。隱性模式時(shí)，該值必須為“token”。還可以為我們自己注冊的擴(kuò)展值。如果一個(gè)授權(quán)請求確實(shí)該參數(shù)，或者授權(quán)服務(wù)器無法理解該參數(shù)，將返回一個(gè)錯(cuò)誤的響應(yīng)。

? ? 3.1.2?重定向終結(jié)點(diǎn)（Redirection Endpoint）

? ? ? ? ? ? ??在完成與資源所有者的交互之后，授權(quán)服務(wù)器將資源所有者的用戶代理引導(dǎo)回客戶端。重定向終結(jié)點(diǎn)URI必須為完整的URI，端點(diǎn)的URI可能包括一個(gè)“application/x-www-form-urlencoded”格式的查詢組件，但不能包含“fragment?”組件。

? ? ?3.1.2.1 終結(jié)點(diǎn)請求機(jī)密性（Endpoint Request Confidentiality）

? ? ? ? ? ? ??當(dāng)請求的響應(yīng)類型為“code”或“token”時(shí)，或者當(dāng)我們要傳送機(jī)密的憑證信息時(shí)，這個(gè)時(shí)候需要使用TLS。該規(guī)范并不強(qiáng)制使用TLS，因?yàn)樵诰帉懘艘?guī)范時(shí)，要求客戶機(jī)部署TLS是許多客戶機(jī)開發(fā)人員的一個(gè)重要障礙。如果TLS不可用，在重定向到授權(quán)服務(wù)器之前，應(yīng)該警告資源所有者不安全端點(diǎn)的情況。

? ? ? ? ? ? ??傳輸層安全性的缺乏會(huì)嚴(yán)重影響客戶端和授權(quán)訪問的受保護(hù)資源的安全性。當(dāng)授權(quán)過程作為客戶端委托的終端用戶身份驗(yàn)證的一種形式時(shí)（例如：第三方登錄服務(wù)），傳輸層安全性的使用尤為重要。

? ? ?3.1.2.1?注冊要求（Registration Requirements）

? ? ? ? ? ? ? 授權(quán)服務(wù)器只接受下面的客戶端的注冊：

公共客戶端
使用隱式授權(quán)類型的機(jī)密客戶端

? ? ? ? ? ? ? 在使用授權(quán)服務(wù)器之前，應(yīng)該要求所有的客戶端來注冊他們的完成授權(quán)后的重定向端點(diǎn)。客戶機(jī)可以使用“state”請求參數(shù)來實(shí)現(xiàn)每個(gè)請求定制。如果要求完全重定向URI的注冊是不可能的,授權(quán)服務(wù)器應(yīng)該要求URI scheme, authority, and path的注冊（允許客戶端動(dòng)態(tài)的改變重定向URI的查詢組）。授權(quán)服務(wù)器也允許客戶端注冊多個(gè)重定向端點(diǎn)。缺少重定向URI注冊要求，增加攻擊者利用授權(quán)端點(diǎn)的風(fēng)險(xiǎn)。

? ? ??3.1.2.1?動(dòng)態(tài)配置（Dynamic Configuration）

? ? ? ? ? ? ??如果多個(gè)重定向URI已注冊，或者只有重定向URI的一部分已被注冊，或者重定向URL沒有被注冊，則在客戶端的授權(quán)請求的查詢組件中，必須包含"redirect_uri"參數(shù)。當(dāng)一個(gè)重定向的URI被包含在授權(quán)請求中時(shí)，授權(quán)服務(wù)器必須跟以注冊的客戶端重定向URI作比較和匹配，如果沒有就跟客戶端本身的URL作比較。

? ? ?3.1.2.2?無效端點(diǎn)（Invalid Endpoint）

? ? ? ? ? ? ??如果由于授權(quán)請求參數(shù)缺失，無效，或者不能匹配無效的URI，授權(quán)服務(wù)器應(yīng)該告知一個(gè)錯(cuò)誤給資源所有者。

? ? ?3.1.2.2?端點(diǎn)內(nèi)容（Endpoint Content）

? ? ? ? ? ? ? 返回給客戶端的請求通常是一個(gè)HTML文檔。如果HTML響應(yīng)作為重定向請求的結(jié)果直接送達(dá)，則HTML文檔中包含的任何腳本都將執(zhí)行對重定向URI及其所包含的憑據(jù)的完全訪問。在重定向端點(diǎn)的響應(yīng)中，客戶端不應(yīng)該包含任何第三方的腳本，相反它應(yīng)該提取出憑證，然后重定向用戶代理到另外的不會(huì)暴露憑證信息的端點(diǎn)。如果，包含第三方腳本，客戶端必須保證首先執(zhí)行自己的腳本。

? ? 3.2 令牌端點(diǎn)（Token Endpoint）

? ? ? ? ? ? ? 令牌端點(diǎn)被客戶端用來獲取訪問令牌（通過呈現(xiàn)一個(gè)包含授權(quán)信息的授權(quán)許可）或者刷新令牌。除了隱式授權(quán)類型（訪問令牌是直接頒發(fā)的。）外，其他的三種授權(quán)許可類型都會(huì)使用令牌端點(diǎn)。? ? ??

? ? ? ? ? ? ? 客戶端獲取令牌端點(diǎn)地址的方法超過了本規(guī)范的范疇，但是通常都是在一個(gè)服務(wù)文檔中提供。

? ? ? ? ? ? ? 因?yàn)閷α钆贫它c(diǎn)的請求會(huì)涉及到憑證的明文傳輸，所有要求必須使用TLS，并且必須使用Post方法。

? ? ? 3.2.1?客戶端授權(quán)（Client Authentication）

? ? ? ? ? ? ? 當(dāng)向令牌端點(diǎn)發(fā)起請求時(shí)，為機(jī)密客戶端和其他的客戶端頒發(fā)的客戶端憑證必須和授權(quán)服務(wù)器進(jìn)行授權(quán)。

強(qiáng)制頒發(fā)刷新令牌和授權(quán)碼給客戶端。當(dāng)授權(quán)碼被以一種非安全的方式傳輸?shù)街囟ㄏ蚨它c(diǎn)，或者重定向URI沒有被完全的注冊。
通過禁用客戶端或更改其憑據(jù)來，從受損客戶機(jī)中恢復(fù)，從而防止攻擊者濫用被盜的刷新令牌。畢竟改變單一的一組客戶端憑證比注銷整個(gè)刷新令牌要快的多。
實(shí)現(xiàn)認(rèn)證管理最佳實(shí)踐，需要定期證書輪換。實(shí)現(xiàn)整套刷新令牌的輪換是具有挑戰(zhàn)性的，而實(shí)現(xiàn)單一的客戶端證書輪換非常的簡單。

? ? ? ? ? ? ?當(dāng)發(fā)送請求的令牌端點(diǎn)時(shí)，客戶可以使用“client_id”請求參數(shù)標(biāo)識本身。在通過“authorization_code”和“grant_type”對令牌端點(diǎn)發(fā)起請求時(shí)，未經(jīng)身份驗(yàn)證的客戶端必須發(fā)送“client_id”以防止自己無意間接受一個(gè)來自于其他客戶端“client_id”的代碼。這樣也防止客戶端的授權(quán)碼被替換，但是這并不對受保護(hù)的資源提供額外的安全性保障。

? ? 3.2 訪問令牌范圍（Access Token Scope）

? ? ? ? ? ? ?通過在請求中添加參數(shù)"scope"，授權(quán)端點(diǎn)和令牌端點(diǎn)允許客戶端指定請求所訪問的范圍。同樣的，授權(quán)服務(wù)器也是用“scope”響應(yīng)參數(shù)來表示頒發(fā)給客戶端的訪問令牌的范圍。“scope”參數(shù)的值表示為空格分隔的、區(qū)分大小寫的字符串的列表。該字符串由授權(quán)服務(wù)器定義。

? ? ? ? ? ? 基于授權(quán)服務(wù)器的策略和資源所有者的指示，授權(quán)服務(wù)器可能會(huì)完全或者部分忽略客戶端請求的“scope”參數(shù)。如果已發(fā)布的訪問令牌范圍與客戶端請求的范圍不同，授權(quán)服務(wù)器必須包含“scope”響應(yīng)參數(shù)，告知客戶端實(shí)際范圍授予。

? ? ? ? ? ??如果客戶端在請求授權(quán)時(shí)省略了范圍參數(shù)，則授權(quán)服務(wù)器必須使用預(yù)先定義的范圍默認(rèn)值處理請求，或者失敗指示無效范圍的請求。授權(quán)服務(wù)器應(yīng)該記錄它的范圍要求和默認(rèn)值。

4、獲取授權(quán)（Obtaining Authorization）

? ? ??為了獲得一個(gè)訪問令牌，客戶端需要向資源所有者獲得授權(quán)，授權(quán)以許可（authorization grant）的形式被呈現(xiàn)。OAuth定義了4中許可類型：authorization code（授權(quán)碼）, implicit（隱性）,resource owner password credentials（資源所有者密碼憑證）, and client credentials（客戶端憑證）。它也提供了擴(kuò)展的機(jī)制來定義額外的授權(quán)許可類型。

? ? 4.1 授權(quán)碼許可類型（Authorization Code Grant）

? ? ? ? ? ? ? 授權(quán)碼許可類型可以用于獲取訪問令牌和刷新令牌，它是為機(jī)密客戶端憑證優(yōu)化的。由于這是一個(gè)基于重定向的流程，客戶端必須能夠與資源所有者的用戶代理（通常是一個(gè)webbrowser）進(jìn)行交互，并能夠接收來自于授權(quán)服務(wù)器的傳入請求（重定向）。

     +----------+| Resource ||   Owner  ||          |+----------+^|(B)+----|-----+          Client Identifier      +---------------+|         -+----(A)-- & Redirection URI ---->|               ||  User-   |                                 | Authorization ||  Agent  -+----(B)-- User authenticates --->|     Server    ||          |                                 |               ||         -+----(C)-- Authorization Code ---<|               |+-|----|---+                                 +---------------+|    |                                         ^      v(A)  (C)                                        |      ||    |                                         |      |^    v                                         |      |+---------+                                      |      ||         |>---(D)-- Authorization Code ---------'      ||  Client |          & Redirection URI                  ||         |                                             ||         |<---(E)----- Access Token -------------------'+---------+       (w/ Optional Refresh Token)
     注意：通過上圖可以看到，到客戶端經(jīng)過用戶代理時(shí)，（A）、（B）、（C）被分成了兩步。
                           圖3：授權(quán)碼流程
    （A）客戶端通過重定向資源所有者的用戶代理重定向到授權(quán)服務(wù)器（注意資源服務(wù)與授權(quán)服務(wù)不是同一臺服務(wù)器），并在請求中包含客戶端標(biāo)識符、請求的范圍、本地狀態(tài)、重定向URI等參數(shù)，一旦授權(quán)服務(wù)器許可或者拒絕后，就會(huì)返回到用戶代理。
    （B）授權(quán)服務(wù)器認(rèn)證資源所有者（通過用戶代理），確定資源所有者的許可，或者拒絕客戶端的訪問請求。
    （C）假如資源所有者許可訪問，根據(jù)早前在客戶端認(rèn)證階段提供的重定向URI，并攜帶參數(shù)授權(quán)碼和本地狀態(tài)（早前在客戶端認(rèn)證階段提供的）,重定向用戶代理到客戶端。
    （D）通過在請求中包含授權(quán)碼和重定向URI，客戶端從令牌端點(diǎn)獲取訪問令牌。
    （E）授權(quán)服務(wù)器驗(yàn)證授權(quán)碼和重定向URI（和客戶端認(rèn)證階段提供的重定向URI進(jìn)行匹配），如果有效，攜帶訪問令牌和刷新令牌（可選）響應(yīng)返回。

? ? 4.1.1?授權(quán)請求（Authorization Request）

? ? ? ? ? ? ? 通過添加下列參數(shù)到查詢組件（query component）中（注意使用?"application/x-www-form-urlencoded" ），發(fā)起對授權(quán)端點(diǎn)URI的請求。

? ? ? ? ? ? ??response_type（請求類型）：必須，值必須為“code”

? ? ? ? ? ? ? client_id（客戶端身份標(biāo)識）：必須

? ? ? ? ? ? ??redirect_uri（重定向URI）：可選

? ? ? ? ? ? ??scope（請求的范圍）：可選

? ? ? ? ? ? ??state（客戶端本地狀態(tài)）：必須，客戶機(jī)用來維護(hù)請求和回調(diào)之間的狀態(tài)的不透明值。當(dāng)將用戶代理重定向回客戶端時(shí)，授權(quán)服務(wù)器包含此值。該參數(shù)應(yīng)用于防止跨站點(diǎn)請求偽造。

? ? ? ? ? ? ? 通過Http重定向響應(yīng)或者其他用戶代理能夠接受的方式，客戶端將資源所有者導(dǎo)向已構(gòu)建好的URI。例如，客戶端指導(dǎo)用戶代理來發(fā)起下面的Http請求：

? ? ? ? ? ? ??GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1

? ? ? ? ? ? ? Host: server.example.com

? ? ? ? ? ? ? 授權(quán)服務(wù)器驗(yàn)證請求來保證所有必須的參數(shù)都存在和有效。如果請求有效，授權(quán)服務(wù)器通過認(rèn)證資源所有者來獲得授權(quán)決定。如果授權(quán)決定被許可，授權(quán)服務(wù)器就會(huì)重定向用戶代理到客戶端提供的重定向URI。

? ? 4.1.2?授權(quán)響應(yīng)（Authorization Response）

? ? ? ? ? ? ? 如果資源所有者許可訪問請求，授權(quán)服務(wù)頒發(fā)一個(gè)授權(quán)碼，并以"application/x-www-form-urlencoded"格式添加下列參數(shù)到重定向URI查詢組件（query）中。

? ? ? ? ? ? ? code：必須。由授權(quán)服務(wù)器生成的授權(quán)碼。授權(quán)碼被頒發(fā)后，必須短暫過期，降低泄露風(fēng)險(xiǎn)，最長的生命周期推薦10分鐘，客戶端只能使用一次授權(quán)碼；如果被第二次使用時(shí)，授權(quán)服務(wù)器必須注銷頒發(fā)給該授權(quán)碼的所有令牌。

? ? ? ? ? ? ? state：狀態(tài)。如果該參數(shù)在之前的客戶端授權(quán)請求中被包含，則返回時(shí)必須原封不動(dòng)的帶上此參數(shù)。

? ? ? ? ? ? ? 例如：授權(quán)服務(wù)器通過發(fā)送下面的Http 響應(yīng)重定向用戶代理到客戶端。

? ? ? ? ? ? ??HTTP/1.1 302 Found

? ? ? ? ? ? ??Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

? ? ?客戶端必須忽略不能識別的響應(yīng)參數(shù)，授權(quán)碼字符串的長度本規(guī)范并未定義。客戶端應(yīng)該避免對授權(quán)碼長度的猜測，授權(quán)服務(wù)器應(yīng)該記錄下所頒發(fā)的授權(quán)碼的長度。

? ? 4.1.2.1 錯(cuò)誤響應(yīng)（Error Response）

? ? ? ? ? ? ? 如果由于缺失、無效、不匹配重定向URI和客戶端標(biāo)識符，授權(quán)服務(wù)器應(yīng)該通知資源所有者錯(cuò)誤，不能自動(dòng)的重定向用戶代理到無效的重定向URI。

? ? ? ? ? ? ? 如果資源所有者拒絕客戶端的訪問請求，授權(quán)碼服務(wù)器應(yīng)該使用"application/x-www-form-urlencoded"格式添加下列參數(shù)到重定向URI的查詢組件（query component）中。

? ? ? ? ? ? ? error：必須。一個(gè)簡單的、來自于包含下面參數(shù)的?ASCII 錯(cuò)誤代碼。

? ? ? ? ? ? ? ? ?invalid_request（無效請求）：請求缺少所需的參數(shù)，包括無效的參數(shù)值，其中包含一次以上的參數(shù)，或者是其他格式錯(cuò)誤的。

? ? ? ? ? ? ? ? ?unauthorized_client（未授權(quán)的客戶端）：客戶端沒有授權(quán)使用此方法請求授權(quán)碼。

? ? ? ? ? ? ? ? ?access_denied（訪問拒絕）：資源所有者或者授權(quán)服務(wù)器拒絕請求。

? ? ? ? ? ? ? ? ?unsupported_response_type（不支持的響應(yīng)類型）：授權(quán)服務(wù)器不支持使用此方法獲得授權(quán)代碼。

? ? ? ? ? ? ? ? ?invalid_scope（無效的請求范圍）：請求的范圍無效、未知或格式錯(cuò)誤。

? ? ? ? ? ? ? ? ?server_error（服務(wù)器錯(cuò)誤）：授權(quán)服務(wù)器遇到意外情況，阻止它執(zhí)行請求（因?yàn)楫?dāng)重定向時(shí)，一個(gè)500內(nèi)部錯(cuò)誤Http狀態(tài)碼不能返回給客戶端，所以這個(gè)錯(cuò)誤碼是必須的。）。

? ? ? ? ? ? ? ? ?temporarily_unavailable（暫時(shí)不可用）：由于臨時(shí)服務(wù)器超載或維護(hù)，授權(quán)服務(wù)器目前無法處理請求。

? ? ? ? ? ? ? error_description（錯(cuò)誤的描述）：可選。提供額外信息，人類可讀的ASCII碼文本字符串。幫助客戶端的開發(fā)者理解發(fā)生的錯(cuò)誤。

?? ? ? ? ? ? ?error_uri（錯(cuò)誤URI）：可選。帶有錯(cuò)誤信息的且可讀的Web頁面，用于向客戶端開發(fā)人員提供關(guān)于錯(cuò)誤的附加信息。

? ? ? ? ? ? ? state（狀態(tài)）：可選。如果在客戶機(jī)授權(quán)請求中存在“state”參數(shù)，則需要原封不動(dòng)的返回。

? ? ? ? ? ? ? 例如：授權(quán)服務(wù)器通過發(fā)送下面的Http 響應(yīng)重定向用戶代理到客戶端。? ? ? ?

? ? ? ? ? ? ? HTTP/1.1 302 Found

? ? ? ? ? ? ? Location: https://client.example.com/cb?error=access_denied&state=xyz

? ? 4.1.3?訪問令牌請求（Access Token Request）

? ? ? ? ? ? ? 客戶端對令牌端點(diǎn)發(fā)送請求，并添加下列參數(shù)到查詢組件（query component）中（注意使用?"application/x-www-form-urlencoded" ），在在HTTP請求實(shí)體中使用utf-8字符編碼。

? ? ? ? ? ? ? grant_type（授權(quán)許可類型）：必須。值必須為“authorization_code”?

? ? ? ? ? ? ? code（授權(quán)碼）：必須。從認(rèn)證服務(wù)器請求的授權(quán)碼。

? ? ? ? ? ? ? redirect_uri（重定向URI）：必須。如果重定向URI被包含在授權(quán)請求中，則值必須與客戶端認(rèn)證階段包含的重定向URI相同。

? ? ? ? ? ? ? client_id（客戶端身份標(biāo)識）：必須。如果客戶端不使用授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證。如果客戶端類型是機(jī)密的，或者客戶端已經(jīng)被頒發(fā)的憑證，或者被分配其他的授權(quán)要求，則客戶端必須使用授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證。

? ? ? ? ? ? ??例如，客戶端使用TLS發(fā)送以下HTTP請求：

     POST /token HTTP/1.1Host: server.example.comAuthorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencodedgrant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
     授權(quán)服務(wù)器必須：

- 如果客戶端類型是機(jī)密的，或者客戶端已經(jīng)被頒發(fā)的憑證，或者被分配其他的授權(quán)要求，則客戶端必須使進(jìn)行身份驗(yàn)證。
- 如果客戶端認(rèn)證被包含，則認(rèn)證客戶端。
- 確保授權(quán)碼被發(fā)送到經(jīng)身份驗(yàn)證的機(jī)密客戶機(jī)，或者被頒發(fā)給請求中“client_id”標(biāo)識的公開客戶端。
- 審核授權(quán)碼是否有效。
- 如果“redirect_uri”被包含在請求中，確保與之前客戶端認(rèn)證階段提供的“redirect_uri”參數(shù)相等。

? ? 4.1.4?訪問令牌響應(yīng)（Access Token Response）

? ? ? ? ? ? ? 如果訪問令牌請求有效并已被授權(quán)，則授權(quán)服務(wù)需頒發(fā)一個(gè)必須的訪問令牌和一個(gè)可選的刷新令牌。如果請求客戶端認(rèn)證失敗或者無效，授權(quán)服務(wù)器將返回錯(cuò)誤的響應(yīng)。

? ? ? ? ? ? ? 成功響應(yīng)的例子：? ? ? ?

     HTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: no-cache{"access_token":"2YotnFZFEjr1zCsicMWpAA","token_type":"example","expires_in":3600,"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA","example_parameter":"example_value"}

? ?4.2?隱性許可類型（Implicit Grant）

? ? ? ? ? ? ?隱式許可類型用于獲取訪問令牌（不支持發(fā)行刷新令牌），并且它對運(yùn)行特定重定向URI的公共客戶機(jī)進(jìn)行了優(yōu)化。?這些客戶機(jī)通常使用JavaScript等腳本語言實(shí)現(xiàn)，并運(yùn)行在客戶端中。由于這是一個(gè)基于重定向的流程，客戶端必須能夠與資源所有者的用戶代理（通常一個(gè)web瀏覽器）進(jìn)行交互，并且能夠接受來自于授權(quán)服務(wù)傳入（通過重定向）的請求。

? ? ? ? ? ? ?不像授權(quán)碼許可類型，客戶端分別請求授權(quán)和訪問令牌，而是直接接收訪問令牌作為授權(quán)請求的結(jié)果。?隱式授權(quán)類型不包括客戶端身份驗(yàn)證，依賴于資源所有者的存在和重定向URI的注冊。因?yàn)樵L問令牌被編碼到重定向URI中，所以它可能暴露在資源所有者和駐留在同一設(shè)備上的其他應(yīng)用程序中。

+----------+| Resource ||  Owner   ||          |+----------+^|(B)+----|-----+          Client Identifier     +---------------+|         -+----(A)-- & Redirection URI --->|               ||  User-   |                                | Authorization ||  Agent  -|----(B)-- User authenticates -->|     Server    ||          |                                |               ||          |<---(C)--- Redirection URI ----<|               ||          |          with Access Token     +---------------+|          |            in Fragment|          |                                +---------------+|          |----(D)--- Redirection URI ---->|   Web-Hosted  ||          |          without Fragment      |     Client    ||          |                                |    Resource   ||     (F)  |<---(E)------- Script ---------<|               ||          |                                +---------------++-|--------+|    |(A)  (G) Access Token|    |^    v+---------+|         ||  Client ||         |+---------+
                            圖4：隱性許可流程

    （A）客戶端將資源服務(wù)器的用戶代理導(dǎo)向授權(quán)端點(diǎn)，并包含客戶端標(biāo)識、請求范圍、本地狀態(tài)、重定向URI等參數(shù)，一旦訪問被許可，授權(quán)服務(wù)器將返回到用戶代理。
    （B）授權(quán)服務(wù)器認(rèn)證資源所有者，并確定資源所有者是許可還是拒絕客戶端的訪問請求。
    （C）假如資源所有者許可訪問，根據(jù)早前在客戶端認(rèn)證階段提供的重定向URI，并在URI片段（fragment）中包含訪問令牌,重定向用戶代理到客戶端。
    （D）用戶代理保留本地UIR片段，向客戶端Web托管資源服務(wù)器發(fā)起請求。
    （E）客戶端Web托管資源服務(wù)器返回一個(gè)web頁面，并包含能夠在URI片段中的提取訪問令牌（和其他參數(shù)）的腳本。
    （F）用戶代理執(zhí)行腳本，提取訪問令牌（和其他參數(shù)）
    （G）用戶代理將訪問令牌傳送給客戶端。

? ? 4.2.1?授權(quán)請求（Authorization Request）

? ? ? ? ? ? ??通過添加下列參數(shù)到查詢組件（query component）中（注意使用?"application/x-www-form-urlencoded" ），發(fā)起對授權(quán)端點(diǎn)URI的請求。

? ? ? ? ? ? ??response_type（響應(yīng)類型）：必須。值必須為“Token”。

? ? ? ? ? ? ? client_id（客戶端標(biāo)識）：必須。

? ? ? ? ? ? ? redirect_uri（重定向URI）：可選。

? ? ? ? ? ? ? scope（請求的范圍）：可選。

? ? ? ? ? ? ? state（客戶端本地狀態(tài)）：推薦。客戶機(jī)用來維護(hù)請求和回調(diào)之間的狀態(tài)的不透明值。當(dāng)將用戶代理重定向回客戶端時(shí)，授權(quán)服務(wù)器包含此值。該參數(shù)應(yīng)用于防止跨站點(diǎn)請求偽造。

? ? ? ? ? ? ? 通過Http重定向，客戶端將資源所有者導(dǎo)向使用上面參數(shù)構(gòu)造的授權(quán)服務(wù)器URI請求。例如，客戶端指導(dǎo)用戶代理使用TLS來發(fā)起下面的Http請求：

     GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1Host: server.example.com
授權(quán)服務(wù)器驗(yàn)證請求來保證所有必須的參數(shù)都存在和有效。授權(quán)服務(wù)器必須（因?yàn)樾枰鼇頂y帶訪問令牌）驗(yàn)證重定向URI，并與之前客戶端認(rèn)證提供的重定向URI進(jìn)行匹配。如果請求有效，授權(quán)服務(wù)器通過認(rèn)證資源所有者來獲得授權(quán)決定（或者通過其他標(biāo)準(zhǔn)來獲得授權(quán)許可）。如果授權(quán)決定被許可，授權(quán)服務(wù)器就會(huì)重定向用戶代理到客戶端提供的重定向URI。

4.2.2?授權(quán)響應(yīng)（Authorization Response）

? ? ? ??如果資源所有者許可訪問請求，授權(quán)服務(wù)器就會(huì)頒發(fā)一個(gè)訪問令牌，并以"application/x-www-form-urlencoded"格式添加下列參數(shù)到重定向URI片段組件（query fragment）中。

? ? ? ?access_token（訪問令牌）：必須。

? ? ? ?token_type（令牌類型）：必須。

? ? ? ?expires_in（過期時(shí)間）：推薦。訪問令牌的生命周期，值“3600”表示訪問令牌將在一個(gè)小時(shí)后過期。如果省略，授權(quán)服務(wù)器，應(yīng)該設(shè)置一個(gè)默認(rèn)值，或者通過其他的方式提供過期時(shí)間。

? ? ? ?scope（范圍）：可選。如果等同于客戶端請求的范圍則可選，否則必須。

? ? ? ?state（狀態(tài)）：可選。如果在客戶機(jī)授權(quán)請求中存在“state”參數(shù)，則必須原封不動(dòng)的返回。

? ? ? ?授權(quán)服務(wù)器不能頒發(fā)刷新令牌

? ? ? ?例如：授權(quán)服務(wù)器通過發(fā)送下面的Http 響應(yīng)重定向用戶代理。

  HTTP/1.1 302 FoundLocation: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600
開發(fā)人員應(yīng)該注意到一些用戶代理不支持在HTTP“l(fā)ocation”響應(yīng)頭字段中包含一個(gè)片段組件。這樣的客戶端會(huì)要求使用其他方法重定向客戶端，而不是一個(gè)3xx重定向響應(yīng)。例如，返回一個(gè)HTML頁面，其中包含一個(gè)與重定向URI鏈接的動(dòng)作的“繼續(xù)”按鈕。
  客戶端必須忽略不能識別的響應(yīng)參數(shù)，授權(quán)碼字符串的長度本規(guī)范并未定義。客戶端應(yīng)該避免對授權(quán)碼長度的猜測，授權(quán)服務(wù)器應(yīng)該記錄下所頒發(fā)的授權(quán)碼的長度。

? ? 4.2.2.1 錯(cuò)誤響應(yīng)（Error Response）

? ? ? ? ? ? ??如果由于缺失、無效、不匹配重定向URI和客戶端標(biāo)識符，授權(quán)服務(wù)器應(yīng)該通知資源所有者錯(cuò)誤，不能自動(dòng)的重定向用戶代理到無效的重定向URI。