OAuth 2.0（網轉）

?

?

?

（一）背景知識

OAuth 2.0很可能是下一代的“用戶驗證和授權”標準，目前在國內還沒有很靠譜的技術資料。為了弘揚“開放精神”，讓業內的人更容易理解“開放平臺”相關技術，進而長遠地促進國內開放平臺領域的發
展，筆者特意將 OAuth 2.0協議翻譯成中文。

目前 OAuth 2.0還沒有最后定稿，最新的修改版是第? 11個版本，本文下面的翻譯即基于這個第?? 11版本。原文見 http://tools.ietf.org/html/draft-ietf-oauth-v2-11。

（二）術語中英對照表

由于 OAuth協議版本較多（1.0,1.0a,2.0等），并且各個版本中的技術術語也各不相同，關于英文技術術語與中文的對應關系，我們以 OAuth 2.0的第? 11版本中的描述為準。
另外有一些情況，一些英文術語不容易找到普遍接受的漢語釋義，翻譯過來反而可能引起誤解，而英文術語本身可能更容易理解，因此就不考慮對這部分詞匯做翻譯了。比如，
“web service”、“endpoint”、“user-agent”、“URI”、“cookie”等，你只需要知道它是什么就好了。還有一些特別難于翻譯的詞匯，比如“profile”，這個詞用在協議里，大概表
示：協議功能的某個剖面、子集、子視圖或輪廓。如果翻譯成“視圖”，容易讓人想到“view”這個詞，產生沖突，最后，我在這里創造了一個新詞匯：“子態”。
下面是整理出來的重要技術術語的中英對照表：
云計算? —— cloud computing
第三方? —— third-party
應用/程序? —— application
私有證書? —— credential
身份驗證? —— authentication
授權? —— authorization
明文? —— clear-text
客戶端? —— client {譯者注：本文中的客戶端與平常所說的“客戶端”并不相同，是相對資源服務器和
授權服務器來說的，它可能指第三方應用的服務器程序或客戶端程序}
服務器? —— server
資源擁有者? —— resource owner
受保護資源? —— protected resource
資源服務器? —— resource server
訪問令牌? —— access token
授權服務器? —— authorization server
訪問許可? —— access grant
實體? —— entity
簽名? —— signature
刷新令牌? —— refresh token
作用域? —— scope
授權碼? —— authorization code
標識符? —— identifier
密鑰? —— secret
斷言? —— assertion
原生程序? —— native application
子態? —— profile
同源策略? —— same-origin policy
回調? —— callback
自治的? —— autonomous
查詢參數部分? —— query component
分段參數部分? —— fragment component
媒體類型? —— media type
廠商特性的? —— vendor-specific
增強型巴科斯范式? —— ABNF
互聯網編號分配機構? —— IANA
互聯網工程指導組? —— IESG
標準軌道? —— standards-track

（三）中文譯本

1.引言
隨著分布式 web service和云計算的使用越來越多，第三方應用需要能訪問到一些服務器托管資源。這些資源通常都是受保護的，并且要求使用資源擁有者的私有證書（典型的證書是用戶名和密碼）進
行身份驗證。在傳統的基于客戶端-服務器的身份驗證模型中，客戶端為了訪問服務器的受保護資源，是使用資源擁有者的私有證書來做身份驗證的。為了讓第三方應用能夠訪問受保護資源，資源擁有者
必需將他/她/它的私有證書透露給第三方。這引出了很多問題并存在很多局限性：

?第三方應用需要用明文保存資源擁有者的私有證書（一般是密碼），留作以后再次使用。

?雖然密碼驗證會造成安全隱患，服務器仍然需要支持用密碼做身份驗證（對稱的密碼驗證）。

?第三方應用對資源擁有者的受保護資源獲得過多的使用權限，而資源擁有者沒有能力限制訪問到某個資源子集，限制持續時間，或限制這些資源所能支持的訪問方式。

?資源擁有者無法在不影響所有第三方的前提下單獨撤銷某個第三方的訪問權限，他/她/它只能通過修改密碼來回收所有權限。

OAuth通過將客戶端和資源擁有者的角色進行分離來解決這些問題。在? OAuth中，客戶端（通常不是資源擁有者，而是代表資源擁有者來操作）提出請求來訪問由資源擁有者控制并由資源服務器托管
的資源，然后得到與資源擁有者不同的一套私有證書。

客戶端并不是直接使用資源擁有者的私有證書來訪問受保護資源，而是得到一個訪問令牌——一個代表某一特定作用域、持續時間和其它屬性的字符串{譯者注：非常重要的一個概念，英文叫? access
token}。訪問令牌由授權服務器在資源擁有者的授意下分發給第三方客戶端。客戶端使用訪問令牌來訪問由資源服務器托管的受保護資源。

例如，一個 web用戶（資源擁有者）能夠準許一個打印服務（客戶端）訪問她存儲在另一個照片共享服務（資源服務器）中的照片，而不用將她的用戶名和密碼透露給這個打印服務。她在一個被該照
片分享服務信任的身份驗證服務（授權服務器）上完成驗證，而這個驗證服務會將特定于委托服務的私有證書（令牌）分發給原打印服務。

基于資源服務器對安全的需求，訪問令牌可以有不同的格式、結構和使用方式（例如密碼學特性）。訪問令牌的屬性和用以訪問受保護資源的方式不在本規范的規定范圍之內，而是由相關的其它規范來
定義。授權服務器和資源服務器之間的交互方式不在本規范的規定范圍之內。

1.1.符號規范
這篇文檔中的關鍵詞“必須”、“一定不能”、“要求”、“會”、“不會”、“應該”、“不應該”、“建議”、“可以”、“可選的”，遵從[RFC2119]中的解釋。

這篇文檔使用出自[I-D.ietf-httpbis-p1-messaging]的增強型巴科斯范式（ABNF）標記法。另外，介紹一些規則定義的出處：URI-Reference出自[RFC3986]；OWS、RWS和?? quoted-string出自
[I-D.ietf-httpbis-p1-messaging]。除非特別提到，否則所有協議參數的名字和值都是大小寫敏感的。

1.2.專業術語解釋
受保護資源：能夠使用 OAuth請求獲取的訪問限制性資源。

資源服務器：能夠接受和響應受保護資源請求的服務器。

客戶端：獲取授權和發送受保護資源請求的應用。

資源擁有者：能夠對受保護資源進行訪問許可控制的實體。

終端用戶：起到資源擁有者角色的用戶。

令牌：分發給客戶端的代表訪問授權的字符串。通常這個字符串對客戶端來說是不透明的。令牌代表資源擁有者許可的訪問作用域和持續時間，并由資源服務器和授權服務器強制保證。這個令牌可以代
表一個標識符，用于檢索授權信息，或以一種可驗證的方式自包含授權信息（即一個包含數據和簽名的令牌字符串）。令牌可能只代表純粹的訪問能力。而為了讓客戶端使用令牌，也可能需要一些多余
的特定驗證證書。

訪問令牌：被客戶端用來代表資源擁有者發送驗證請求的令牌。

刷新令牌：被客戶端用來獲取新的訪問令牌的令牌，而不用資源擁有者的參與。

授權碼：一個短期令牌，代表終端用戶的授權。授權碼用于獲取一個訪問令牌和一個刷新令牌。

訪問許可：用于描述中間形式的私有證書（如終端用戶的密碼或授權碼）的一個通用詞匯，代表資源擁有者的授權。客戶端使用訪問許可來獲取訪問令牌。通過將各種形式的訪問許可都交換成訪問令牌，
資源服務器只需要支持一種驗證機制。

授權服務器：能夠成功驗證資源擁有者和獲取授權，并在此之后分發令牌的服務器。授權服務器可以和資源服務器是同一個服務器，也可以是不同的實體。單獨一個授權服務器可以為多個資源服務器分
發令牌。

終端用戶授權 endpoint：授權服務器上能夠驗證終端用戶并獲取授權的 HTTP endpoint。終端用戶授權 endpoint在第 4節詳細描述。

令牌 endpoint：授權服務器上能夠分發令牌和刷新過期令牌的 HTTP endpoint。令牌 endpoint在第? 5節詳細描述。

客戶端標識符：分發給客戶端的唯一標識，用于客戶端向授權服務器標識自己。客戶端標識符可以有一個對應的密鑰。客戶端標識符在第 3節詳細描述。

1.3.概述
OAuth為客戶端提供了一種代表資源擁有者訪問受保護資源的方法。在客戶端訪問受保護資源之前，它必須先從資源擁有者獲取授權（訪問許可），然后用訪問許可交換訪問令牌（代表許可的作用域、
持續時間和其它屬性）。客戶端通過向資源服務器出示訪問令牌來訪問受保護資源。

訪問令牌提供了一個抽象層，將不同的授權結構（如用戶名密碼、斷言）替換成資源服務器可以理解的單一令牌。這種抽象使得分發短期有效的訪問令牌成為可能，也使得資源服務器不必理解多種多樣
的授權機制。

圖 1:抽象的協議流程

圖 1所示的抽象流程協議的總體架構，它包含下列步驟：
(A)客戶端從資源擁有者那里請求授權。授權請求能夠直接發送給資源擁有者，或者間接地通過授權
服務器這樣的中介，而后者更為可取。
(B)客戶端收到一個訪問許可，它代表由資源服務器提供的授權。
(C)客戶端使用它自己的私有證書到授權服務器上驗證，并出示訪問許可，來請求一個訪問令牌。
(D)授權服務器驗證客戶端私有證書和訪問許可的有效性，如果驗證通過則分發一個訪問令牌。
(E)客戶端通過出示訪問令牌向資源服務器請求受保護資源。
(F)資源服務器驗證訪問令牌的有效性，如果驗證通過則響應這個資源請求。

1.4訪問許可
訪問許可代表資源擁有者提供的授權。訪問許可的類型取決于客戶端使用的獲取方式和授權服務器所支持的方式。

1.4.1授權碼
授權碼是通過將終端用戶引導到授權服務器而獲得的一種訪問許可。授權服務器驗證終端用戶，獲得授權，然后向客戶端分發一個授權碼。因為終端用戶只在授權服務器上進行驗證，所以終端用戶的密
碼從來不用分享給客戶端。

當客戶端通過一個 user-agent同終端用戶進行交互的時候，授權碼這種訪問許可是很合適的。

圖 2:獲取授權碼

圖 2所示的授權碼獲取流程包含下列步驟：

(A)客戶端通過將終端用戶的?? user-agent引導到授權服務器的終端用戶授權 endpoint來發起這個流程。客戶端傳入標識符、請求作用域、本地狀態，和一個重定向 URI（在訪問被許可或被拒絕后授權
服務器會重新將 user-agent引導回這個? URI）。

(B)授權服務器驗證終端用戶的身份（通過?? user-agent），并且確定終端用戶是許可還是拒絕了客戶端的訪問請求。

(C)如果訪問被許可，授權服務器會使用重定向?? URI將 user-agent引導回客戶端。授權服務器傳回一個授權碼給客戶端，用于進一步獲取訪問令牌。

一旦客戶端獲得了授權碼，它會到授權服務器上去做驗證（使用客戶端私有證書）并出示授權碼（訪問許可），以借此請求一個訪問令牌。在客戶端無法維護它自己的私有證書的情況下（如原生程序或用某種
user-agent腳本實現的程序），授權服務器在(C)步直接給客戶端分發一個訪問令牌，而不再分發一個授權碼。獲得授權碼的過程在第 4節詳述。

1.4.2資源擁有者密碼證書
資源擁有者密碼證書（例如用戶名和密碼）可以直接用作訪問許可來獲取訪問令牌。這種私有證書只應該在以下兩種情況下使用：當在資源擁有者和客戶端之間有很強的信任關系的時候（例如，資源擁
有者的計算機操作系統，或具有很高特權的程序），以及當其它訪問許可類型（如授權碼）不可用的時候。

即使這種許可類型需要客戶端直接訪問資源擁有者的私有證書，資源擁有者的私有證書也只是在一個請求中使用，并交換成訪問令牌。與[RFC2617]定義的 HTTP Basic驗證機制不同，這種許可類型不再
需要客戶端存儲資源擁有者的私有證書以備日后使用。

??????????????????????????????????????????????????????????????????????????????????? 圖 3:獲取資源擁有者密碼證書

?

在圖 3中，客戶端直接從資源擁有者請求授權。當資源擁有者是一個終端用戶時，客戶端通常的做法是提示終端用戶輸入用戶名和密碼。

1.4.3客戶端私有證書
當授權作用域限制在客戶端所控制的受保護資源或之前與授權服務器約定好的受保護資源時，客戶端本身的私有證書可被用作訪問許可。客戶端私有證書用作訪問許可的典型例子是，當客戶端代表它自
己執行操作時（客戶端同時也是資源擁有者）。

1.4.4刷新令牌
訪問令牌的生命周期通常比資源擁有者授予的要短一些。當分發一個訪問令牌時，授權服務器可以同時傳回一個刷新令牌，在當前訪問令牌超時后，客戶端可以用這個刷新令牌重新獲取一個訪問令牌。
當請求新的訪問令牌時，刷新令牌擔當起訪問許可的角色。使用刷新令牌，不再需要再次與資源擁有者交互，也不需要存儲原始的訪問許可來獲得訪問令牌和刷新令牌。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖 4:刷新訪問令牌

?

圖 4所示的刷新令牌流程包含下列步驟：

(A)客戶端通過使用它自己的私有證書在授權服務器上驗證，并出示一個訪問許可。

(B)授權服務器驗證客戶端私有證書和訪問許可的有效性，如果通過則分發一個訪問令牌和刷新令牌。

(C)客戶端通過出示訪問令牌向資源服務器請求受保護資源。

(D)資源服務器驗證訪問令牌的有效性，如果通過，則相應這個請求。

(E)步驟(C)(D)不停重復，直到訪問令牌過期。如果客戶端不知道訪問令牌過期，它會再請求一次受保護資源。否則，跳到步驟(G)。

(F)因為訪問令牌是無效的（過期了），資源服務器返回一個無效令牌錯誤。

(G)客戶端通過使用它的私有證書在授權服務器上驗證并出示刷新令牌（用作訪問許可），來請求一個新的訪問令牌。

(H)授權服務器驗證客戶端私有證書的有效性，如果通過則分發一個新的訪問令牌（也可能還有一個刷新令牌）。

?
1.4.5斷言
斷言在 OAuth和其它信任框架之間架起一座橋梁。它們允許客戶端利用現成的信任關系來獲取訪問令牌。一個斷言所代表的訪問許可取決于斷言類型、斷言內容，以及斷言被分發的方式，而這些內容
不在本規范的規定范圍之內。斷言可以用在協議擴展模型的部分，它為授權服務器提供了一種支持其它訪問許可類型的方式。

2.客戶端的各種子態

2.1 Web Server子態
Web Server子態適用于有能力與終端用戶的? user-agent（通常是瀏覽器）交互并能夠從授權服務器接收（通過重定向）請求（即有能力擔當 HTTP服務器的角色）的客戶端。

????????????????????????????????????????????????????????????????????????????????????? 圖 5: Web Server流程

?

圖 5所示的 web? server流程包含下列步驟：

(A)如第? 4節所述，web客戶端通過將終端用戶的?? user-agent重定向到授權服務器來發起這個流程。客戶端傳入它的客戶端標識符、請求作用域、本地狀態和一個重定向 URI，在訪問被許可（或被拒絕）
后授權服務器會重新將終端用戶引導回這個 URI。

(B)授權服務器驗證終端用戶（借助于?? user-agent），并確定終端用戶是否許可客戶端的訪問請求。

(C)假定終端用戶許可了這次訪問，授權服務器會將?? user-agent重定向到之前提供的重定向 URI上去。授權服務器為客戶端傳回一個授權碼做獲取訪問令牌之用。

(D)如第? 5節所述，客戶端通過驗證并傳入上一步取得的授權碼從授權服務器請求一個訪問令牌。

(E)授權服務器驗證客戶端私有證書和授權碼的有效性并返回訪問令牌。

2.2 User-Agent子態
User-Agent子態適用于常駐? user-agent的客戶端應用，典型的例子是用諸如 JavaScript語言編寫并運行在瀏覽器的程序。這些客戶端不能保存客戶端私有證書，并且客戶端的驗證基于 user-agent的
同源策略。

在其它子態中，客戶端對于終端用戶的授權和訪問令牌使用分開的不同請求來完成，而與之不同的是，在 user-agent子態中，客戶端以? HTTP重定向的方式在終端用戶授權請求的結果中獲取到訪問令牌。
客戶端請求授權服務器將user-agent重定向到另一個web服務器或user-agent能訪問到的本地資源，而且 user-agent有能力從響應信息中提取出訪問令牌并傳給客戶端。

這種 user-agent子態并不使用客戶端密鑰，因為客戶端執行程序常駐于終端用戶的計算機或設備上，這使得客戶端密鑰可以被訪問或收集到。因為訪問令牌被編碼到重定向 URI中，所以它可能會暴露給
終端用戶和常駐計算機或設備上的其它應用。
?

??????????????????????????????????????????????????????????????????????????????????????????????????? 圖 6: User-Agent流程

?

圖 6所示的 user-agent流程包含下列步驟：

(A)如第? 5節所述，客戶端將? user-agent引導到終端用戶授權? endpoint。客戶端傳入它的客戶端標識符、請求作用域、本地狀態和一個重定向 URI，在訪問被許可（或被拒絕）后授權服務器會重新將
終端用戶引導回這個 URI。

(B)授權服務器驗證終端用戶（通過? user-agent）并確認終端用戶是許可還是拒絕了客戶端的訪問請求。

(C)如果終端用戶許可了這次訪問，那么授權服務器會將?? user-agent引導到之前提供的重定向 URI。重定向 URI會在 URI片斷{譯者注：URI片斷是指?? URI中#號之后的內容}中包含訪問令牌。

(D) user-agent響應重定向指令，向? web服務器發送不包含? URI片斷的請求。user-agent在本地保存 URI片斷。

(E) web服務器返回一個? web頁面（通常是嵌入了腳本的 HTML網頁），這個頁面能夠訪問完整的重定向 URI，它包含了由 user-agent保存的 URI片斷，同時這個頁面能夠將包含在? URI片斷中的訪問
令牌（和其它參數）提取出來。

(F) user-agent在本地執行由? web服務器提供的腳本，該腳本提取出訪問令牌并將它傳遞給客戶端。

2.3原生程序
原生程序是作為原生代碼運行在終端用戶計算機或設備上的客戶端（即，在 user-agent之外運行或作為一個桌面程序）。這些客戶端通常有能力與終端用戶的 user-agent交互（或嵌入? user-agent），
但是在這些交互如何影響終端用戶體驗的方式上受到限制。在很多情況下，原生程序無法直接從服務器接收回調請求（例如，防火墻、操作系統限制）。

基于不同的需求和期望的終端用戶體驗，原生程序客戶端可以用不同的方式實現。原生程序客戶端可以：
如第 4節所述，通過啟動一個外部? user-agent來訪問終端用戶授權 endpoint。客戶端可以通過下面的方式捕獲響應文本：提供一個具有自定義 URI scheme{譯者注：URI scheme就是一個?? URI
里面的第一部分，即冒號前面的部分}的重定向 URI（在操作系統上注冊過以便調用客戶端應用），或者提供一個指向在客戶端控制下的服務器資源的重定向 URI，這使得響應文本對客戶端可見（例如，
使用窗口標題或在 user-agent外面可以訪問到的其它位置）。

如第 4節所述，通過嵌入一個? user-agent來訪問終端用戶授權 endpoint。客戶端通過與嵌入的 user-agent直接通信獲取到響應文本。提示終端用戶輸入密碼，使用密碼直接獲得一個訪問令牌。通常
來講，這是一種不推薦的方式，因為它將終端用戶的密碼直接交給了第三方客戶端，而客戶端不得不用明文存儲密碼。它還要求服務器支持基于密碼的身份驗證。當在啟動外部瀏覽器和嵌入的 user-agent
之間進行選擇時，開發者應該考慮下列因素：
外部瀏覽器可能會提高完成比率，因為終端用戶可能已經登錄過了而不需要重新進行身份驗證。
嵌入的 user-agent通常能提供更好的用戶流程，因為它不必切換上下文并打開新窗口。
嵌入的 user-agent對安全提出了挑戰，因為用戶在一個無法辨別的窗口之中進行身份驗證，而不像很多 user-agent那樣能提供可視化的保護。

2.4自治態

自治客戶端使用現成的信任關系或框架來建立授權。基于自治客戶端的需求和他們所依賴的現存信任框架，自治客戶端可以用不同的方式實現。自治客戶端可以：

?通過使用客戶端私有證書與授權服務器進行驗證，從而獲得訪問令牌。訪問令牌的作用域局限于受客戶端控制的受保護資源，或者其它資源擁有者與授權服務器預先約定的資源。

?使用現存的某種訪問許可，它被表達成授權服務器所支持的某種斷言格式。使用斷言需要客
戶端從一個斷言發行方獲得一個斷言（如 SAML[OASIS.saml-core-2.0-os]斷言）或自己分發一個斷言。
斷言的格式、獲得斷言的過程，以及驗證斷言的方法，由斷言發行方和授權服務器定義，不在本規范
的規定范圍之內。


3.客戶端私有證書
當與授權服務器進行交互時，客戶端使用一個私有證書集合來標識自己，這個證書集合包含一個客戶端標識符和用于客戶端身份驗證的其它一些屬性。客戶端獲得私有證書的方式不在本規范的規定范圍
之內，不過這通常都包含一個在授權服務器上注冊的過程。

考慮到一些客戶端的本質特性，在與客戶端沒有確立信任關系的前提下，授權服務器不應該對客戶端密鑰的私密性做出任何假設。授權服務器不應該向沒有能力對密鑰進行秘密保存的客戶端分發密鑰。

授權服務器可以使用任一合適的私有證書集合和驗證機制來對客戶端進行身份驗證。客戶端一定不能在一個請求中使用多個私有證書集合和驗證機制。

3.1客戶端密碼證書
客戶端密碼證書使用一個共享的對稱密鑰來驗證客戶端。客戶端標識符和密碼被包含在請求當中，使用[RFC2617]定義的 HTTP Basic驗證機制，將客戶端標識符作為用戶名（username）并將客戶端密
碼作為密碼（password）來傳送。例如（換行符只用于顯示目的）：

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

作為可選方式，客戶端可以使用下列參數將密碼包含在請求體（request body）中：

client_id?? 必需參數。客戶端標識符。

client_secret? 必需參數。客戶端密鑰。

例如（換行符只用于顯示目的）：

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&client_id=s6BhdRkqt3&
client_secret=gX1fBat3bV&code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

授權服務器必須能夠使用請求參數和 HTTP Basic驗證協議兩種方式接受客戶端私有證書。授權服務器可以支持更多適合于密碼證書傳輸的驗證機制

3.2客戶端斷言證書
客戶端斷言證書用于不宜使用密碼（明文共享對稱密鑰）或密碼無法為客戶端驗證提供足夠安全性的情況。在這樣的情況下，常見的做法是使用諸如 HMAC或數字簽名之類不需要發送明文密鑰的其它機
制。客戶端斷言證書提供了一種擴展機制，能夠使用被授權服務器所支持的某種斷言格式進行客戶端身份驗證。

使用斷言需要客戶端從一個斷言發行方獲得一個斷言（如 SAML[OASIS.saml-core-2.0-os]斷言）或自己分發一個斷言。斷言的格式、獲得斷言的過程，以及驗證斷言的方法，由斷言發行方和授權服務器
定義，不在本規范的規定范圍之內。

當使用客戶端斷言時，客戶端傳送下列參數：

client_assertion_type? 必需參數。由授權服務器定義的斷言格式。這個值必須是一個絕對 URI。
client_assertion? 必需參數。客戶端斷言。

例如，客戶端使用一個 SAML 2.0斷言發送如下訪問令牌請求來驗證自己（換行符只用于顯示目的）：

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=i1WsRn1uB1&
client_assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D&
client_assertion_type=
urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

?當使用一個客戶端斷言和一個授權碼獲得一個訪問令牌的時候，需要一個機制在用于獲取授權碼的“client_id”參數值和客戶端斷言之間完成映射。這個機制不在本規范的規定范圍之內，但對于與授權
碼結合使用的任何客戶端斷言類型都必須明確指明。

對于那些使用客戶端斷言證書但不包含能夠提供下列信息的 HMAC或簽名值的訪問令牌請求，授權服務器必須拒絕響應：
?指明這個斷言是專門分發給當前接收 endpoint來處理的（一般是通過一個包含接收? endpoint標識符的 audience或? recipient值）。

?標識出分發斷言的實體（一般是通過一個 issuer值）。

?用一個絕對時間標識出斷言在何時過期（一般是通過一個包含 UTC日期/時間值的過期值）。
授權服務器必須拒絕過期的斷言。

4.獲得終端用戶授權
在客戶端能夠訪問一個受保護資源之前，它必須首先從終端用戶那里獲取授權。為了獲得終端用戶授權，客戶端需要將終端用戶引導到終端用戶授權 endpoint。一旦獲得授權，終端用戶的訪問許可會被
表示成一個授權碼，客戶端能夠使用它去獲取一個訪問令牌。

在終端用戶授權 endpoint上，終端用戶首先在授權服務器上完成身份驗證，然后允許或者拒絕當前訪問請求。授權服務器驗證用戶的方式（例如，用戶名和密碼登錄，OpenID，會話 cookie）和授權
服務器獲取終端用戶授權的方式，以及是否使用諸如 TSL之類的安全通道，不在本規范的規定范圍之內。然而，授權服務器必須要首先驗證終端用戶的身份。

終端用戶授權 endpoint的位置能夠在服務器文檔中找到。終端用戶授權? endpoint的 URI可以按照[RFC3986]第 3節的定義包含一個查詢參數部分，它們在添加其它參數時必須被保留。

既然對于終端用戶授權 endpoint的請求會導致用戶身份驗證和敏感信息的傳輸，授權服務器應該要求在向終端用戶授權 endpoint發送請求的時候使用諸如? TLS之類的傳輸層安全機制。

?