OAuth 2.0中文譯本

時間 2019-12-09

標籤 oauth 2.0 中文譯本简体版

原文原文鏈接

（一）背景知識javascript

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

目前OAuth 2.0尚未最後定稿，最新的修改版是第11個版本，本文下面的翻譯即基於這個第11版本。原文見http://tools.ietf.org/html/draft-ietf-oauth-v2-11。java

關於OAuth 2.0的更多背景知識，請參考個人另外一篇文章：http://itgeeker.com/mathml/readpaper?pid=65web

（二）術語中英對照表json

因爲OAuth協議版本較多（1.0,1.0a,2.0等），而且各個版本中的技術術語也各不相同，關於英文技術術語與中文的對應關係，咱們以OAuth 2.0的第11版本中的描述爲準。瀏覽器

另外有一些狀況，一些英文術語不容易找到廣泛接受的漢語釋義，翻譯過來反而可能引發誤解，而英文術語自己可能更容易理解，所以就不考慮對這部分詞彙作翻譯了。好比，「web service」、「endpoint」、「user-agent」、「URI」、「cookie」等，你只須要知道它是什麼就行了。安全

還有一些特別難於翻譯的詞彙，好比「profile」，這個詞用在協議裏，大概表示：協議功能的某個剖面、子集、子視圖或輪廓。若是翻譯成「視圖」，容易讓人想到「view」這個詞，產生衝突，最後，我在這裏創造了一個新詞彙：「子態」。服務器

下面是整理出來的重要技術術語的中英對照表：cookie

雲計算 —— 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) 客戶端收到一個訪問許可，它表明由資源服務器提供的受權。

(D) 受權服務器驗證客戶端私有證書和訪問許可的有效性，若是驗證經過則分發一個訪問令牌。

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

(F) 資源服務器驗證訪問令牌的有效性，若是驗證經過則響應這個資源請求。

1.4 訪問許可

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

1.4.1 受權碼

受權碼是經過將終端用戶引導到受權服務器而得到的一種訪問許可。受權服務器驗證終端用戶，得到受權，而後向客戶端分發一個受權碼。由於終端用戶只在受權服務器上進行驗證，因此終端用戶的密碼歷來不用分享給客戶端。

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

圖2: 獲取受權碼

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

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

(B) 受權服務器驗證終端用戶的身份（經過user-agent），而且肯定終端用戶是許可仍是拒絕了客戶端的訪問請求。

一旦客戶端得到了受權碼，它會到受權服務器上去作驗證（使用客戶端私有證書）並出示受權碼（訪問許可），以藉此請求一個訪問令牌。

在客戶端沒法維護它本身的私有證書的狀況下（如原生程序或用某種user-agent腳本實現的程序），受權服務器在(C)步直接給客戶端分發一個訪問令牌，而再也不分發一個受權碼。

得到受權碼的過程在第4節詳述。

1.4.2 資源擁有者密碼證書

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

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

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

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

1.4.3 客戶端私有證書

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

1.4.4 刷新令牌

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

圖4: 刷新訪問令牌

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

(A) 客戶端經過使用它本身的私有證書在受權服務器上驗證，並出示一個訪問許可。

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

(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），並肯定終端用戶是否許可客戶端的訪問請求。

(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）並確認終端用戶是許可仍是拒絕了客戶端的訪問請求。

(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處理（使用iesg@iesg.org郵件組）。

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