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 2.0的更多背景知識，請參考我的另一篇文章：http://itgeeker.com/mathml/readpaper?pid=65
（二）術語中英對照表
由於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之類的傳輸層安全機制。
4.1 授權請求
為了將終端用戶的user-agent引導到授權服務器，客戶端將下列參數添加到終端用戶授權endpoint URI的查詢參數部分，並使用如[W3C.REC-html401-19991224]所定義的“application/x-www-form-urlencoded”格式構建起一個請求URI，如下定義：
response_type
必需參數。請求的響應中：一個訪問令牌、一個授權碼，或兩者都有。請求訪問令牌參數值必須設為“token”，請求授權碼參數值必須設為“code”，或者使用參數值為“code_and_token”同時請求兩者。授權服務器可能拒絕提供這些響應類型中的一種或多種。
client_id
必需參數。如第3節所述的客戶端標識符。
redirect_uri
必需參數，除非通過其它方式在客戶端和授權服務器之間已經確定了一個重定向URI。這是當終端用戶的授權步驟完成時授權服務器將要把user-agent重定向到的一個絕對URI。授權服務器應該要求客戶端預先註冊它們的重定向URI。
scope
可選參數。訪問請求的作用域，以空格隔開的字符串列表來表示。“scope”參數的值由授權服務器定義。如果這個值包含多個空格隔開的字符串，那麽它們的順序不分先後，而且每個字符串都為請求的作用域增加一個新的訪問範圍。
state
可選參數。被客戶端用來在請求和回調之間維護狀態的值，對授權服務器來說是不透明的。授權服務器在將user-agent重定向回客戶端時傳回這個值。
客戶端通過user-agent使用HTTP重定向響應，或者其它可用的方式，將終端用戶引導到構建好的URI上。對於終端用戶授權endpoint，授權服務器必須支持HTTP的“GET”方法，也可以支持使用“POST”方法。
例如，客戶端引導終端用戶的user-agent使用傳輸層安全機制發送下列HTTP請求（換行符只用於顯示目的）:
GET /authorize?response_type=code&client_id=s6BhdRkqt3&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
如果客戶端已經在授權服務器上預先註冊了一個重定向URI，授權服務器必須保證收到的重定向URI與當前客戶端標識符所對應的註冊URI相匹配。授權服務器不應該將user-agent重定向到沒有註冊過的或不信任的URI，以避免endpoint被用作一個公開的轉向器。如果沒有可用的有效重定向URI，授權服務器應該將發生的錯誤報告給用戶[[提供如何執行匹配操作的建議]]。
沒有值的參數必須被當做它們在請求中不存在一樣。授權服務器應該忽略識別不了的請求參數。
授權服務器對請求進行驗證以保證所有必需參數都存在並有效。如果請求是無效的，授權服務器將使用重定向URI把user-agent重定向回客戶端，並且URI後面加上適當的錯誤碼，如4.3節所述。
授權服務器驗證終端用戶的身份並獲得一個授權決定（通過詢問用戶或通過其它方式認可）。當一個決定被做出後，授權服務器將終端用戶的user-agent引導到客戶端提供的重定向URI，這個重定向或者使用HTTP重定向響應，或者通過終端用戶user-agent的其它可用的方式。
4.2 授權響應
如果終端用戶許可了訪問請求，授權服務器會分發一個訪問令牌，或一個授權碼，或者兩者都有，並且通過將下列參數添加到重定向URI將這些分發結果傳遞給客戶端（如下所述）。
code
如果響應類型是“code”或“code_and_token”則是必需的，否則一定不能包含這個參數。表示由授權服務器產生的授權碼。授權碼應該在分發後迅速過期，以降低泄露風險。客戶端一定不能重用同一個授權碼。如果一個授權碼被多次使用，授權服務器可能撤銷之前基於這個授權碼分發的所有令牌。授權碼與客戶端標識符和重定向URI相綁定。
access_token
如果響應類型是“token”或“code_and_token”則是必需的，否則一定不能包含這個參數。表示由授權服務器分發的訪問令牌。
token_type
如果響應中包含一個訪問令牌則是必需的。表示分發的令牌類型。令牌類型告訴客戶端一個信息，即當訪問一個受保護資源時訪問令牌應該如何被使用，如6.1節所述。
expires_in
可選參數。如果包含訪問令牌參數，則表示訪問令牌生命周期的秒數。例如，“3600”表示自響應被授權服務器產生的時刻起，訪問令牌將在一小時後過期。
scope
可選參數。如果包含訪問令牌參數，則表示訪問令牌的作用域，表示為一個空格隔開的字符串列表。“scope”參數的值由授權服務器定義。如果這個值包含多個空格隔開的字符串，那麽它們的順序不分先後，而且每個字符串都為請求的作用域增加一個新的訪問範圍。如果請求到的作用域不同於客戶端申請的作用域，授權服務器應該傳回這個參數。
state
如果“state”參數在客戶端授權請求中存在，則這個參數是必需的。需要精確地設置成從客戶端接收到的值。
授權服務器在重定向URI上添加參數的方式取決於客戶端在授權請求中請求的響應類型，由“response_type”參數指定。
如果響應類型是“code”，授權服務器使用如[W3C.REC-html401-19991224]所定義的“application/x-www-form-urlencoded”格式添加參數到重定向URI的查詢參數部分。
例如，授權服務器通過發送下列HTTP響應將終端用戶的user-agent進行重定向：
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=i1WsRn1uB1
如果響應類型是“code”或“code_and_token”，授權服務器使用如[W3C.REC-html401-19991224]所定義的“application/x-www-form-urlencoded”格式添加參數到重定向URI的分段參數部分。
例如，授權服務器通過發送下列HTTP響應將終端用戶的user-agent進行重定向（URI換行符只用於顯示目的）：
HTTP/1.1 302 Found
Location: http://example.com/rd#access_token=FJQbwq9&
token_type=example&expires_in=3600
客戶端應該忽略無法識別的響應參數。從授權服務器接收到的令牌和其它參數值的大小，本規範未作定義。客戶端應該避免對參數值大小做任何假設。服務器應該對它們所分發的任何參數值的期望大小做出文檔說明。
4.3 錯誤響應
如果終端用戶拒絕了訪問請求，或者由於除了缺少或無效重定向URI之外的其它原因而導致請求失敗，授權服務器使用如[W3C.REC-html401-19991224]所定義的“application/x-www-form-urlencoded”格式添加下列參數到重定向URI的查詢參數部分以通知客戶端：
error
必需參數。如4.3.1節所述的一個錯誤碼。
error_description
可選參數。提供額外信息的一段人類可讀的文字，用來幫助理解和解決發生的錯誤。
error_uri
可選參數。指明了一個人類可讀的網頁URI，帶有關於錯誤的信息，用來為終端用戶提供與錯誤有關的額外信息。
state
如果“state”參數在客戶端授權請求中存在，則這個參數是必需的。需要精確地設置成從客戶端接收到的值。
例如，授權服務器通過發送下列HTTP響應將終端用戶的user-agent進行重定向：
HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied
如果由於缺少或無效重定向URI而導致請求失敗，授權服務器應該通知終端用戶這個錯誤，而一定不能將終端用戶的user-agent重定向到這個無效的重定向URI。
4.3.1 錯誤碼
授權服務器在錯誤響應中包含下列錯誤碼之一：
invalid_request
請求缺少某個必需參數，包含一個不支持的參數或參數值，或者格式不正確。
invalid_client
提供的客戶端標識符是無效的。
unauthorized_client
客戶端沒有權限使用該請求的響應類型。
redirect_uri_mismatch
提供的重定向URI與預先註冊的值不匹配。
access_denied
終端用戶或授權服務器拒絕了請求。
unsupported_response_type
請求的響應類型不為授權服務器所支持。
invalid_scope
請求的作用域是無效的、未知的，或格式不正確的。
[[增加擴展錯誤碼的機制]]
5. 獲取訪問令牌
客戶端通過在授權服務器上驗證並出示它的訪問許可（表示成授權碼、資源擁有者私有證書、斷言或刷新令牌的形式）來獲取一個訪問令牌。
既然對於令牌endpoint的請求會導致在HTTP請求和響應中傳輸明文證書，授權服務器必需要求在向令牌endpoint發送請求的時候使用傳輸層安全機制。服務器必需支持[RFC5246]所定義的TLS 1.2，並且可能支持額外的傳輸層安全機制。
客戶端通過向令牌endpoint發送一個HTTP POST請求來獲取一個訪問令牌。令牌endpoint的位置能夠在服務器文檔中找到。令牌endpoint URI可能包含一個查詢參數部分。
客戶端通過在請求中添加客戶端私有證書與授權服務器進行驗證，如第3節所述。當客戶端標識符不重要的時候（例如匿名客戶端），或當客戶端標識符通過其它方式確定的時候（例如使用一個斷言訪問許可），授權服務器可能允許不經驗證的訪問令牌請求。
客戶端通過在HTTP請求的entity-body中使用“application/x-www-form-urlencoded”格式包含下列參數，來構建請求：
grant_type
必需參數。在請求中所包含的訪問許可類型。它的值必須是“authorization_code”、“password”、“refresh_token”、“client_credentials”或一個用來標識被授權服務器所支持的斷言類型的絕對URI。
scope
可選參數。訪問請求的作用域，表達為一個由空格隔開的字符串列表。“scope”參數的值由授權服務器定義。如果這個值包含多個空格隔開的字符串，那麽它們的順序不分先後，而且每個字符串都為請求的作用域增加一個新的訪問範圍。如果使用的訪問許可已經代表了一個許可作用域（例如，授權碼、斷言），那麽請求的作用域必須等於或少於之前許可的作用域，如果缺少這個參數就認為是等於之前的許可作用域。
另外，對於5.1節列出的某個訪問許可類型，客戶端必須包含合適的參數。
沒有值的參數必須被當做它們在請求中不存在一樣。授權服務器應該忽略識別不了的請求參數。
5.1 訪問許可類型
客戶端使用一個授權碼、資源擁有者密碼證書、客戶端私有證書、刷新令牌或斷言來請求一個訪問許可。
5.1.1 授權碼
客戶端使用“authorization_code”訪問許可類型和下列參數傳入授權碼：
code
必需參數。從授權服務器接收到的授權碼。
redirect_uri
必需參數。在最初請求中使用的重定向URI。
例如，客戶端通過如第3節所述的“client_secret”參數包含客戶端私有證書，並使用傳輸層安全機制，來發送下列HTTP請求（換行符只用於顯示目的）：
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
授權服務器必須：
· 驗證客戶端私有證書（如果存在）並保證它們與授權碼匹配。
· 驗證授權碼和重定向URI都是有效的，並且與存儲的關聯關系相匹配。
如果請求有效，授權服務器分發一個成功響應，如5.2節所述。
5.1.2 資源擁有者密碼證書
客戶端使用“password”訪問許可類型和下列參數傳入資源擁有者密碼證書：[[增加對於用戶名和密碼的國際化考慮]]
username
必需參數。資源擁有者的用戶名。
password
必需參數。資源擁有者的密碼。
例如，客戶端通過如第3節所述的“client_secret”參數包含客戶端私有證書，並使用傳輸層安全機制，來發送下列HTTP請求（換行符只用於顯示目的）：
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=password&client_id=s6BhdRkqt3&
client_secret=47HDu8s&username=johndoe&password=A3ddj3w
授權服務器必須驗證客戶端私有證書（如果存在）和終端用戶私有證書，而且如果發現有效則必須發布一個訪問令牌響應，如5.2節所述。
5.1.3 客戶端私有證書
客戶端可以僅僅使用它的客戶端私有證書來請求一個訪問令牌，即使用“client_credentials”訪問許可類型。當省略一個顯式的訪問許可時，客戶端是在請求訪問它所控制的受保護資源，或另一個資源擁有者之前與授權服務器約定好的受保護資源（約定方式不在本規範的規定範圍之內）。
5.1.4 刷新令牌
客戶端使用“refresh_token”訪問許可類型和下列參數傳入刷新令牌：
refresh_token
必需參數。與待刷新的訪問令牌相關聯的刷新令牌。
例如，客戶端通過如第3節所述的“client_secret”參數包含客戶端私有證書，並使用傳輸層安全機制，來發送下列HTTP請求（換行符只用於顯示目的）：
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&client_id=s6BhdRkqt3&
client_secret=8eSEIpnqmM&refresh_token=n4E9O119d
授權服務器必須驗證客戶端私有證書（如果存在），驗證刷新令牌是否有效，以及驗證資源擁有者的授權是否仍然有效。如果請求有效，授權服務器則發布一個訪問令牌響應，如5.2節所述。授權服務器可以發布一個新的刷新令牌，在這種情況下，客戶端必須丟棄舊的刷新令牌並且用新的訪問令牌替換。
5.1.5 斷言
客戶端使用一個絕對URI（由授權服務器定義）作為“grant_type”參數的值指定斷言格式，並添加下列參數，來傳入一個斷言：
assertion
必需參數。斷言。
例如，客戶端使用傳輸層安全機制來發送下列HTTP請求，且客戶端驗證通過斷言來完成（換行符只用於顯示目的）：
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertion&
assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D
授權服務器必須驗證客戶端私有證書（如果存在）和斷言，而且如果發現有效則必須發布一個訪問令牌響應，如5.2節所述。授權服務器不應該分發一個刷新令牌（而是應該要求客戶端使用相同的或新的斷言）。
授權服務器應該分發具有有限生命周期的訪問令牌，並且要求客戶端使用仍然有效的同一個斷言來請求新的訪問令牌，從而完成對令牌的刷新。
5.2 訪問令牌響應
在接收到並驗證過來自客戶端的一個有效且經授權的訪問令牌請求之後，授權服務器分發訪問令牌和可選的刷新令牌，並且通過一個200（OK）狀態碼在HTTP響應的entity body中添加下列參數來構造響應：
令牌響應包含下列參數：
access_token
必需參數。由授權服務器分發的訪問令牌。
token_type
必需參數。分發的令牌類型。令牌類型告訴客戶端一個信息，即當訪問一個受保護資源時訪問令牌應該如何被使用，如6.1節所述。
expires_in
可選參數。訪問令牌生命周期的秒數。例如，“3600”表示自響應被授權服務器產生的時刻起，訪問令牌將在一小時後過期。
refresh_token
可選參數。用來獲取新的訪問令牌的刷新令牌，如5.1.4節所述使用相同的終端用戶訪問許可。當訪問許可類型是一個斷言或一個客戶端私有證書集合時，授權服務器不應該分發一個刷新令牌。
scope
可選參數。訪問令牌的作用域，表示為一個空格隔開的字符串列表。“scope”參數的值由授權服務器定義。如果這個值包含多個空格隔開的字符串，那麽它們的順序不分先後，而且每個字符串都為請求的作用域增加一個新的訪問範圍。如果請求到的作用域不同於客戶端申請的作用域，授權服務器應該傳回這個參數。
參數包含在HTTP響應的entity body中，使用[RFC4627]定義的“application/json”媒體類型。通過在最高結構層次上添加每個參數，將它們序列化成一個JSON結構。參數名和字符串值都表示成JSON字符串。數字值表示成JSON數字。
在任何包含令牌、密鑰或其它敏感信息的響應中，授權服務器必須在“Cache-Control”響應頭部字段中傳入一個“no-store”的值。
例如：
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token":"SlAV32hkKG",
"token_type":"example",
"expires_in":3600,
"refresh_token":"8xLOxBtZp8"
}
客戶端應該忽略無法識別的響應參數。從授權服務器接收到的令牌和其它參數值的大小，本規範未作定義。客戶端應該避免對參數值大小做任何假設。服務器應該對它們所分發的任何參數值的期望大小做出文檔說明。
5.3 錯誤響應
如果令牌請求是無效的或未經授權的，授權服務器通過在HTTP響應的entity body中添加下列參數並使用“application/json”媒體類型來構造響應：
error
必需參數。如4.3.1節所述的一個錯誤碼。
error_description
可選參數。提供額外信息的一段人類可讀的文字，用來幫助理解和解決發生的錯誤。
error_uri
可選參數。指明了一個人類可讀的網頁URI，帶有關於錯誤的信息，用來為終端用戶提供與錯誤有關的額外信息。
例如：
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error":"invalid_request"
}
如果客戶端通過“Authorization”請求頭部字段使用HTTP驗證機制這種方式提供了無效的私有證書，那麽授權服務器必須用HTTP 401（Unauthorized）狀態碼進行響應。否則，授權服務器應該用HTTP 400（Bad Request）狀態碼進行響應。
5.3.1 錯誤碼
授權服務器在錯誤響應中傳回下列錯誤碼之一：
invalid_request
請求缺少某個必需參數，包含一個不支持的參數或參數值，參數重復，包含多個私有證書，使用了多種驗證客戶端的機制，或者請求格式不正確。
invalid_client
提供的客戶端標識符是無效的，客戶端驗證失敗，客戶端不包含私有證書，提供了多個客戶端私有證書，或使用了不支持的證書類型。
unauthorized_client
經過驗證的客戶端沒有權限使用提供的訪問許可類型。
invalid_grant
提供的訪問許可是無效的、過期的或已撤銷的（例如，無效的斷言，過期的授權令牌，錯誤的終端用戶密碼證書，或者不匹配的授權碼和重定向URI）。
unsupported_grant_type
包含的訪問許可——它的類型或其它屬性——不被授權服務器所支持。
invalid_scope
請求的作用域是無效的、未知的、格式不正確的，或超出了之前許可的作用域。
[[增加擴展錯誤碼的機制]]
6. 訪問受保護資源
客戶端通過向資源服務器出示一個訪問令牌來訪問受保護資源。資源服務器必須驗證訪問令牌，保證它沒有過期並且它的作用域覆蓋了請求的資源。被資源服務器用來驗證訪問令牌的方式不在本規範的規定範圍之內，但是它通常需要在資源服務器和授權服務器之間進行交互或配合。
客戶端利用訪問令牌來驗證資源服務器的方式取決於由授權服務器分發的訪問令牌類型。
6.1 訪問令牌類型
[[增加令牌類型的解釋，可能包含指定其它規範的鏈接]]
6.2 WWW-Authenticate響應頭部字段
如果對於受保護資源的請求不包含驗證證書，包含一個無效的訪問令牌，或格式不正確，那麽資源服務器必須包含一個HTTP “WWW-Authenticate”響應頭部字段。這個“WWW-Authenticate”頭部字段使用[RFC2617]定義的框架，如下所示：
challenge = "OAuth2" [ RWS 1#param ]
param = scope /
error / error-desc / error-uri /
( token "=" ( token / quoted-string ) )
scope = "scope" "=" <"> scope-v *( SP scope-v ) <">
scope-v = 1*quoted-char
quoted-char = ALPHA / DIGIT /
"!" / "#" / "$" / "%" / "&" / "‘" / "(" / ")" /
"*" / "+" / "-" / "." / "/" / ":" / "<" / "=" /
">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" /
"{" / "|" / "}" / "~" / "\" / "," / ";"
error = "error" "=" quoted-string
error-desc = "error_description" "=" quoted-string
error-uri = "error_uri" = <"> URI-reference <">
“scope”屬性是一個空格隔開的作用域值的列表，表明了為了訪問受保護資源所需要訪問令牌作用域。“scope”屬性一定不能出現多次。
如果對於受保護資源的請求包含一個訪問令牌並且驗證失敗了，那麽資源服務器應該包含“error”屬性來向客戶端提供為何訪問請求被拒絕的原因。參數值在6.2.1中描述。另外，資源服務器可能包含“error_description”屬性來提供一個人類可讀的解釋，或者包含“error-uri”屬性用一個絕對URI來指定一個用於解釋錯誤的人類可讀的網頁。“error”、“error_description”和“error-uri”屬性一定不能出現多次。
例如，對於一個缺少驗證的受保護資源請求的響應：
HTTP/1.1 401 Unauthorized
WWW-Authenticate: OAuth2
對於一個使用過期訪問令牌嘗試驗證的受保護資源請求的響應：
HTTP/1.1 401 Unauthorized
WWW-Authenticate: OAuth2
error="invalid_token",
error_description="The access token expired"
6.2.1 錯誤碼
當一個請求失敗時，資源服務器使用恰當的HTTP狀態碼（典型的如400、401或403）進行響應，並且在響應中包含下列錯誤碼之一：
invalid_request
請求缺少某個必需參數，包含一個不支持的參數或參數值，參數重復，使用多種方式包含訪問令牌，或者請求格式不正確。資源服務器應該使用HTTP 400（Bad Request）狀態碼進行響應。
invalid_token
提供的訪問令牌是過期的、已撤銷的、格式不正確的，或由於其它原因是無效的。資源服務器應該使用HTTP 401（Unauthorized）狀態碼進行響應。客戶端可能請求一個新的訪問令牌並重試受保護資源請求。
insufficient_scope
請求需要比訪問令牌所提供的權限更高的權限。資源服務器應該使用HTTP 403（Forbidden）狀態碼進行響應並且包含“scope”屬性，帶上訪問該受保護資源必需的作用域。
[[增加擴展錯誤碼的機制]]
如果請求中缺少任何驗證信息（即客戶端沒有意識到驗證是必需的或嘗試使用一個不支持的驗證方法），那麽資源服務器不應該包含一個錯誤碼和其它錯誤信息。
例如：
HTTP/1.1 401 Unauthorized
WWW-Authenticate: OAuth2
7. 擴展
7.1 定義新的客戶端證書類型
[[待定]]
7.2 定義新的Endpoint參數
希望在終端用戶授權endpoint和令牌endpoint上定義新的請求和響應參數的應用，應該使用下列兩種方式之一：在參數註冊表中註冊（遵從9.1節描述的流程），或使用“x_”參數名前綴。
使用“x_”參數名前綴的參數必須局限於那些不會被廣泛應用的針對廠商特性的擴展，並且特定於授權服務器使用場景的實現細節。所有其它參數必須被註冊，並且一定不能使用“x_”參數名前綴。
參數名必須遵從param-name的ABNF，並且參數值語法必須被規範地定義（例如，使用ABNF，或者引用到現存參數的語法）。
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
7.3 定義新的頭部字段參數
希望在OAuth “WWW-Authenticate”頭部字段中定義新參數的應用必須在參數註冊表中進行註冊，遵從9.1節描述的流程。
參數名必須遵從param-name的ABNF並且不能以“x_”開頭。參數值必須遵從param-value的ABNF並且語法必須被規範地定義（例如，使用ABNF，或者引用到現存參數的語法）。
param-value = quoted-value | quoted-string
7.4 定義新的訪問許可類型
斷言訪問許可類型允許授權服務器接受其它未規定的訪問許可。希望定義其它訪問許可類型的應用能夠通過利用新的或現存的斷言類型和格式進行實現。
8. 安全考慮
[[待定]]
9. IANA事項
9.1 OAuth參數註冊表
本文檔設立參數註冊表。
用於終端用戶授權endpoint的請求、終端用戶授權endpoint的響應、令牌endpoint的請求、令牌endpoint的響應或“WWW-Authenticate”頭部字段的多余參數，在一個或多個“指派專家”（由IESG或他們的代理機構指定）的指導下進行註冊，遵從所需的規範（使用[RFC5226]的術語）。然而，為了允許在發布之前對值進行分配，“指派專家”們一旦認同這樣的一個規範能夠發布，可能就立即批準註冊。
註冊請求應該發送給[待定]@ietf.org郵件組進行評審和討論，使用恰當的標題（如“Request for parameter: example”）。[[RFC-EDITOR註解：郵件組名稱應該在與IESG和IANA磋商後確定。建議名稱：oauth-ext-review。]]
在14天之內，“指派專家”們會批準或拒絕註冊請求，並將結果告知郵件組和IANA。拒絕的決定應該包含一個解釋，並且，如果可行的話，應該包含如何進行修改的建議。在21天以上未確定的註冊請求會交由IESG處理（[email protected]）。
9.1.1 註冊模板
Parameter name: 請求的名稱（例如“example”）。
Parameter usage location: 參數能夠被使用的位置。可能的位置包括：終端用戶授權endpoint的請求、終端用戶授權endpoint的響應、令牌endpoint的請求、令牌endpoint的響應或“WWW-Authenticate”頭部字段。
Change controller: 對於標準軌道的RFC，寫明“IETF”。對於其它規範，使用負責機構的名稱。其它細節（例如，郵編地址，電子郵件地址，主頁URI）也可以包含。
Specification document(s): 對規定參數的文檔引用，可取的方式是包含一個能夠獲取到文檔拷貝的URI。對於相關章節的標示也可以包含，但不是必需的。
Related information: 可選地，對於包含更多相關信息的額外文檔的引述。
9.1.2 例子
下面是對於本規範定義的“scope”參數的參數註冊請求：
Parameter name: scope
Parameter usage location: The end-user authorization endpoint
request, the end-user authorization endpoint response, the token
endpoint request, the token endpoint response, and the
"WWW-Authenticate" header field.
Change controller: IETF
Specification document(s): [[ this document ]]
Related information: None
附錄 翻譯略。
OAuth 2.0中文譯本