本文為 RFC 7591 — OAuth 2.0 Dynamic Client Registration Protocol 的非官方繁體中文翻譯，原文於 2015 年 7 月發布。技術內容與規範要求以英文原文為準。本文保留原文章節編號、協定名稱、參數與範例；移除紙本頁首頁尾，將登錄資料整理為表格。譯者補充均以「譯註」標示，不屬於 RFC 原文。

原作者：Justin Richer（編輯）、Michael B. Jones（Microsoft）、John Bradley（Ping Identity）、Maciej Machulak（Newcastle University）、Phil Hunt（Oracle Corporation）。類別：標準軌（Standards Track）；ISSN：2070-1721。

摘要

本規範定義向授權伺服器動態註冊 OAuth 2.0 用戶端的機制。註冊請求會將一組期望的用戶端中繼資料值傳送給授權伺服器。註冊回應則傳回可在該授權伺服器使用的用戶端識別碼，以及為該用戶端登錄的中繼資料值。用戶端接著即可利用這些註冊資訊，以 OAuth 2.0 協定與授權伺服器通訊。本規範也定義了一組供用戶端在註冊時使用的常見中繼資料欄位與值。

本備忘錄的狀態

這是一份網際網路標準軌文件。

本文件由網際網路工程任務組（IETF）制定，代表 IETF 社群的共識。它已經過公開審查，並獲網際網路工程指導小組（IESG）核准發布。有關網際網路標準的更多資訊，請參閱 RFC 5741 第 2 節。

本文件目前的狀態、勘誤及回饋方式，請見 RFC Editor 的 RFC 7591 資訊頁。

著作權聲明

Copyright © 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

著作權 © 2015 IETF Trust 及本文件所列作者。保留所有權利。

本文件適用於發布當日有效的 BCP 78 與 IETF Trust 關於 IETF 文件的法律條款。請仔細閱讀這些文件，其中說明您對本文件享有的權利及所受的限制。從本文件擷取的程式碼元件，必須包含 Trust 法律條款第 4.e 節所述的 Simplified BSD License 文字，且依該授權條款所述，不提供任何擔保。

目錄

1. 簡介

OAuth 2.0 [RFC6749] 用戶端若要使用 OAuth 2.0 授權伺服器，就需要與該伺服器互動的特定資訊，包括可在該伺服器使用的 OAuth 2.0 用戶端識別碼。本規範說明 OAuth 2.0 用戶端如何向授權伺服器動態註冊，以取得這些資訊。

作為註冊程序的一部分，本規範也定義用戶端向授權伺服器提供一組中繼資料的機制，例如一組有效的重新導向 URI。這些中繼資料可以由用戶端自行宣告，也可以放在稱為「軟體聲明」（software statement）的中繼資料集合中，以數位簽章或訊息鑑別碼（MAC）保護；使用軟體聲明時，簽發者會為用戶端資料的有效性背書。

傳統上，用戶端向授權伺服器註冊是以人工方式進行。本規範定義的機制既可讓用戶端動態地向授權伺服器自行註冊，也可讓用戶端開發者以程式方式進行註冊。先前已有多種使用 OAuth 2.0 的應用程式發展出這類註冊機制。本規範將「OpenID Connect Dynamic Client Registration 1.0」[OpenID.Registration] 定義、以及「User Managed Access (UMA) Profile of OAuth 2.0」[UMA-Core] 使用的註冊機制加以通用化，同時維持與兩者相容，並適用於更廣泛的 OAuth 2.0 使用案例。

1.1. 表示慣例

本文件中的關鍵字「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」與「OPTIONAL」，應依 [RFC2119] 的定義解讀。

除非另有說明，所有協定參數名稱和值皆區分大小寫。

譯註：本文以「必須（MUST）」、「不得（MUST NOT）」、「應（SHOULD）」、「不應（SHOULD NOT）」、「建議（RECOMMENDED）」、「可以（MAY）」、「必要（REQUIRED）」及「選用（OPTIONAL）」保留規範強度。

1.2. 術語

本規範使用 OAuth 2.0 [RFC6749] 定義的「存取權杖」（access token）、「授權碼」（authorization code）、「授權端點」（authorization endpoint）、「授權授予」（authorization grant）、「授權伺服器」（authorization server）、「用戶端」（client）、「用戶端識別碼」（client identifier）、「用戶端密鑰」（client secret）、「授予類型」（grant type）、「受保護資源」（protected resource）、「重新導向 URI」（redirection URI）、「更新權杖」（refresh token）、「資源擁有者」（resource owner）、「資源伺服器」（resource server）、「回應類型」（response type）與「權杖端點」（token endpoint），以及 JSON Web Token（JWT）[RFC7519] 定義的「宣告」（Claim）。

本規範另定義下列術語：

用戶端軟體（Client Software）：實作 OAuth 2.0 用戶端的軟體。

用戶端實例（Client Instance）：某個用戶端軟體的已部署實例。

用戶端開發者（Client Developer）：建置用戶端軟體套件並準備散布的個人或組織。建置用戶端時，開發者通常不知道未來將由哪些服務提供者組織進行部署。若無法在編譯時預測軟體的某些面向，例如部署 URL，就需要使用動態註冊。例如，軟體 API 發布者與部署組織不同時，就可能發生這種情況。

用戶端註冊端點（Client Registration Endpoint）：供用戶端向授權伺服器註冊的 OAuth 2.0 端點。如何取得此端點的 URL，不在本規範範圍內。

初始存取權杖（Initial Access Token）：授權伺服器可選擇簽發給開發者或用戶端的 OAuth 2.0 存取權杖，用來授權對用戶端註冊端點的呼叫。權杖的類型與格式可能依服務而異，不在本規範範圍內。授權伺服器如何簽發、註冊端點如何驗證此權杖，也不在本規範範圍內。當授權伺服器限制哪些對象可以註冊用戶端時，就需要使用初始存取權杖。

部署組織（Deployment Organization）：部署軟體 API（服務）、並以 OAuth 2.0 框架保護它的管理性安全網域。在某些 OAuth 情境中，部署組織與軟體 API 發布者相同；此時，部署組織通常與用戶端軟體開發者關係密切。在其他許多情況中，服務定義者可能是獨立第三方發布者或標準組織。依照已發布的 API 規範開發時，用戶端軟體開發者無法事先與可能部署該軟體 API（服務）的眾多組織建立關係。

軟體 API 部署（Software API Deployment）：在特定部署組織網域中，受到 OAuth 2.0 保護的軟體 API 已部署實例，即受保護資源。一個軟體 API 可以有一個或多個部署。軟體 API 部署通常有相應的 OAuth 2.0 授權伺服器及用戶端註冊端點。如何取得這些端點，不在本規範範圍內。

軟體 API 發布者（Software API Publisher）：定義特定網路可存取 API 的組織；該 API 可以部署於一個或多個環境。發布者可以是標準團體、商業、公營、私人或開源組織，負責發布及散布可透過 OAuth 2.0 保護的軟體與 API 規範。在某些情況下，軟體 API 發布者與用戶端開發者可能是同一組織。發布網路可存取 API 時，軟體發布者通常尚未與部署組織建立關係。

軟體聲明（Software Statement）：經數位簽章或 MAC 保護的 JSON Web Token（JWT）[RFC7519]，用來聲明用戶端軟體的中繼資料值。有時由用戶端開發者直接簽發，有時由第三方組織簽發給用戶端開發者使用。在這兩種情況下，授權伺服器與軟體聲明簽發者之間的信任關係，都應作為評估是否接受註冊請求的依據。軟體聲明可以作為用戶端註冊請求的一部分提交給授權伺服器。

1.3. 協定流程

        +--------(A)- Initial Access Token (OPTIONAL)
        |
        |   +----(B)- Software Statement (OPTIONAL)
        |   |
        v   v
    +-----------+                                      +---------------+
    |           |--(C)- Client Registration Request -->|    Client     |
    | Client or |                                      | Registration  |
    | Developer |<-(D)- Client Information Response ---|   Endpoint    |
    |           |        or Client Error Response      +---------------+
    +-----------+

圖 1：動態用戶端註冊的抽象流程

圖 1 中的抽象 OAuth 2.0 動態用戶端註冊流程，描述用戶端或開發者與本規範所定義端點之間的互動。圖中未呈現錯誤情況。流程包含以下步驟：

  • (A) 可以選擇向用戶端或開發者簽發初始存取權杖，授予用戶端註冊端點的存取權。如何簽發此權杖，不在本規範範圍內。
  • (B) 可以選擇向用戶端或開發者簽發軟體聲明，供用戶端註冊端點使用。如何簽發此聲明，不在本規範範圍內。
  • (C) 用戶端或開發者以期望註冊的用戶端中繼資料呼叫用戶端註冊端點；如果授權伺服器要求，則附上步驟 (A) 取得的初始存取權杖。
  • (D) 授權伺服器註冊該用戶端，並傳回用戶端已註冊的中繼資料、在該伺服器中唯一的用戶端識別碼，以及適用時的一組用戶端憑證，例如用戶端密鑰。

附錄 A 提供不同組態與用法的範例。

2. 用戶端中繼資料

已註冊的用戶端在授權伺服器上，具有一組與用戶端識別碼相關聯的中繼資料值，例如有效的重新導向 URI 清單或顯示名稱。

這些用戶端中繼資料值有兩種用途：作為註冊請求的輸入值，以及註冊回應的輸出值。

本規範定義下列用戶端中繼資料欄位。除非另有說明，所有中繼資料欄位的實作與使用皆為選用（OPTIONAL）。所有資料成員的型別（字串、陣列、數字）皆依其 JSON [RFC7159] 表示方式定義。

redirect_uris

重新導向 URI 字串陣列，供授權碼流程、隱式流程等以重新導向為基礎的流程使用。依 OAuth 2.0 [RFC6749] 第 2 節的要求，使用重新導向流程的用戶端必須（MUST）註冊其重新導向 URI 值。若授權伺服器支援這類流程的動態註冊，就必須（MUST）實作此中繼資料值的支援。

token_endpoint_auth_method

表示所請求的權杖端點驗證方法的字串。本規範定義下列值：

  • none：用戶端是 OAuth 2.0 第 2.1 節所定義的公開用戶端，沒有用戶端密鑰。
  • client_secret_post：用戶端使用 OAuth 2.0 第 2.3.1 節定義的 HTTP POST 參數。
  • client_secret_basic：用戶端使用 OAuth 2.0 第 2.3.1 節定義的 HTTP Basic。

其他值可以透過第 4.2 節建立的 IANA「OAuth Token Endpoint Authentication Methods」登錄表定義。絕對 URI 也可以直接作為此參數的值，無須登錄。若未指定或省略，預設值為 client_secret_basic，表示使用 OAuth 2.0 第 2.3.1 節規定的 HTTP Basic 驗證方案。

grant_types

用戶端可在權杖端點使用的 OAuth 2.0 授予類型字串陣列。授予類型定義如下：

  • authorization_code：OAuth 2.0 第 4.1 節定義的授權碼授予類型。
  • implicit：OAuth 2.0 第 4.2 節定義的隱式授予類型。
  • password：OAuth 2.0 第 4.3 節定義的資源擁有者密碼憑證授予類型。
  • client_credentials：OAuth 2.0 第 4.4 節定義的用戶端憑證授予類型。
  • refresh_token：OAuth 2.0 第 6 節定義的更新權杖授予類型。
  • urn:ietf:params:oauth:grant-type:jwt-bearer：OAuth JWT Bearer Token Profiles [RFC7523] 定義的 JWT Bearer Token 授予類型。
  • urn:ietf:params:oauth:grant-type:saml2-bearer：OAuth SAML 2 Bearer Token Profiles [RFC7522] 定義的 SAML 2.0 Bearer Assertion 授予。

若授予類型使用權杖端點，此參數的值必須（MUST）與該授予類型定義中，傳給權杖端點的 grant_type 參數值相同。授權伺服器可以（MAY）允許其他依 OAuth 2.0 第 4.5 節授予類型擴充程序定義的值。若省略，預設行為是用戶端只使用 authorization_code 授予類型。

response_types

用戶端可在授權端點使用的 OAuth 2.0 回應類型字串陣列。回應類型定義如下：

  • code：OAuth 2.0 第 4.1 節定義的授權碼回應類型。
  • token：OAuth 2.0 第 4.2 節定義的隱式回應類型。

若授予類型使用授權端點，此參數的值必須（MUST）與該授予類型定義中，傳給授權端點的 response_type 參數值相同。授權伺服器可以（MAY）允許其他依 OAuth 2.0 第 4.5 節授予類型擴充程序定義的值。若省略，預設用戶端只使用 code 回應類型。

client_name

在授權時呈現給終端使用者、供人閱讀的用戶端名稱字串。若省略，授權伺服器可以（MAY）改為向終端使用者顯示原始的 client_id 值。建議（RECOMMENDED）用戶端一律傳送此欄位。此欄位值可以（MAY）依第 2.2 節進行國際化。

client_uri

提供用戶端資訊之網頁的 URL 字串。若提供，伺服器應（SHOULD）以可點擊的方式向終端使用者顯示此 URL。建議（RECOMMENDED）用戶端一律傳送此欄位。此欄位值必須（MUST）指向有效的網頁，並可以（MAY）依第 2.2 節進行國際化。

logo_uri

指向用戶端標誌的 URL 字串。若提供，伺服器應（SHOULD）在核准過程中向終端使用者顯示此圖片。此欄位值必須（MUST）指向有效的圖片檔案，並可以（MAY）依第 2.2 節進行國際化。

scope

以空格分隔的範圍值清單字串（如 OAuth 2.0 [RFC6749] 第 3.3 節所述），列出用戶端請求存取權杖時可以使用的範圍。清單中各值的語意由服務自行定義。若省略，授權伺服器可以（MAY）以預設的一組範圍註冊用戶端。

contacts

字串陣列，表示與用戶端負責人聯絡的方法，通常是電子郵件地址。授權伺服器可以（MAY）向終端使用者提供這些聯絡地址，以便提出用戶端支援請求。隱私考量請見第 6 節。

tos_uri

指向供人閱讀之用戶端服務條款文件的 URL 字串。該文件描述終端使用者授權用戶端時所接受、使用者與用戶端之間的契約關係。若提供，授權伺服器應（SHOULD）向終端使用者顯示此 URL。此欄位值必須（MUST）指向有效的網頁，並可以（MAY）依第 2.2 節進行國際化。

policy_uri

指向供人閱讀之隱私政策文件的 URL 字串。該文件描述部署組織如何蒐集、使用、保留及揭露個人資料。若提供，授權伺服器應（SHOULD）向終端使用者顯示此 URL。此欄位值必須（MUST）指向有效的網頁，並可以（MAY）依第 2.2 節進行國際化。

jwks_uri

指向用戶端 JSON Web Key（JWK）Set [RFC7517] 文件的 URL 字串，其中包含用戶端的公開金鑰。此欄位值必須（MUST）指向有效的 JWK Set 文件。這些金鑰可供使用簽章或加密的上層協定使用。例如，某些應用程式在使用 JWT 進行用戶端驗證 [RFC7523] 時，可能用它們驗證向權杖端點發出的已簽章請求。相較於 jwks，較優先使用此參數，因為它較容易輪替金鑰。同一請求或回應中不得（MUST NOT）同時出現 jwks_uri 與 jwks。

jwks

用戶端的 JSON Web Key Set [RFC7517] 文件值，其中包含用戶端的公開金鑰。此欄位值必須（MUST）是包含有效 JWK Set 的 JSON 物件。這些金鑰可供使用簽章或加密的上層協定使用。此參數供無法使用 jwks_uri 的用戶端使用，例如無法託管公開 URL 的原生用戶端。同一請求或回應中不得（MUST NOT）同時出現 jwks_uri 與 jwks。

software_id

由用戶端開發者或軟體發布者指派的唯一識別字串，例如通用唯一識別碼（UUID），讓註冊端點識別要動態註冊的用戶端軟體。授權伺服器簽發的 client_id 應（SHOULD）因實例而異；相較之下，software_id 應（SHOULD）在同一用戶端軟體的所有實例間保持相同。同一軟體經過多次更新或多個版本時，software_id 也應（SHOULD）維持不變。此欄位並非供人閱讀，通常對用戶端與授權伺服器而言都是不透明的值。

software_version

由 software_id 識別之用戶端軟體的版本識別字串。同一 software_id 所識別的用戶端軟體每次更新時，software_version 值應（SHOULD）隨之改變。此欄位預期使用字串相等比對；本規範未定義其他比較語意。其值不在本規範範圍內，但並非供人閱讀，通常對用戶端與授權伺服器而言都是不透明的值。哪些變動構成會觸發此值改變的軟體更新，由軟體自行定義，不在本規範範圍內。

本規範的擴充與設定檔，可以透過依第 4 節 IANA 考量登錄的中繼資料名稱與描述，擴充此清單。授權伺服器必須（MUST）忽略用戶端傳送、但它不理解的中繼資料，例如在處理時靜默移除用戶端註冊記錄中的未知中繼資料。授權伺服器可以（MAY）拒絕任何所請求的中繼資料值，作法包括依第 3.2.1 節以合適預設值取代，或依第 3.2.2 節傳回錯誤回應。

用戶端中繼資料值可以直接放在第 3.1 節所述的註冊請求主體中，也可以依第 2.3 節作為軟體聲明中的宣告，或混合使用兩種方式。若同一中繼資料名稱同時出現在兩處，而且授權伺服器信任該軟體聲明，則必須（MUST）優先採用軟體聲明中的宣告值。

2.1. 授予類型與回應類型之間的關係

上述 grant_types 與 response_types 有部分相互獨立，因為它們分別對應 OAuth 協定不同端點的引數。不過，兩者仍有關聯：用戶端可用的 grant_types 會影響它可使用的 response_types，反之亦然。例如，grant_types 包含 authorization_code，即意味著 response_types 包含 code，因為兩者都屬於 OAuth 2.0 授權碼授予的定義。因此，支援這些欄位的伺服器應（SHOULD）採取措施，確保用戶端不能將自己註冊成不一致的狀態，例如對不一致的註冊請求傳回 invalid_client_metadata 錯誤。

兩個欄位的對應關係如下：

grant_types 包含 response_types 包含
authorization_code code
implicit token
password 無
client_credentials 無
refresh_token 無
urn:ietf:params:oauth:grant-type:jwt-bearer 無
urn:ietf:params:oauth:grant-type:saml2-bearer 無

本文件的擴充與設定檔若為 grant_types 或 response_types 引入新值，必須（MUST）記載這兩種參數之間的所有對應關係。

2.2. 供人閱讀的用戶端中繼資料

供人閱讀的用戶端中繼資料值，以及指向供人閱讀內容的中繼資料值，可以（MAY）用多種語言與文字系統表示。例如，在某些用戶端註冊中，client_name、tos_uri、policy_uri、logo_uri 及 client_uri 等欄位可能有多個適用於不同地區設定的值，以利在各地使用。

指定語言與文字系統時，在中繼資料成員名稱後加上 BCP 47 [RFC5646] 語言標籤，以 # 字元分隔。由於 JSON [RFC7159] 成員名稱區分大小寫，建議（RECOMMENDED）宣告名稱中的語言標籤，採用「IANA Language Subtag」登錄表 [IANA.Language] 登記的大小寫形式。通常語言名稱採小寫、地區名稱採大寫，而語言採大小寫混合。不過，BCP 47 語言標籤值本身不區分大小寫，因此實作應（SHOULD）以不區分大小寫的方式解讀標籤值。依 BCP 47 的建議，中繼資料成員名稱中的語言標籤，只須具體到必要程度。例如，在許多情境下，fr 已經足夠，無須使用 fr-CA 或 fr-FR。

譯註：上段英文原文最後一種大小寫慣例寫作 “languages”，此處忠實保留；依上下文，其所指應為文字系統（script）子標籤。

例如，用戶端可以在同一註冊請求中，以 "client_name#en": "My Client" 表示英文名稱，並以 "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" 表示日文名稱。授權伺服器可以（MAY）在授權步驟中，依系統設定、使用者偏好或其他因素，選擇向資源擁有者顯示其中任何或全部名稱。

若供人閱讀的欄位未附語言標籤，使用它的各方不得（MUST NOT）對字串值的語言、字元集或文字系統作任何假設；在使用者介面呈現時，必須（MUST）原樣使用該字串值。為促進互通性，建議（RECOMMENDED）用戶端與伺服器除了語言專屬欄位之外，也使用不帶語言標籤的供人閱讀欄位；也建議（RECOMMENDED）這些未附語言標籤的欄位包含適合在多種系統上顯示的值。

實作者注意事項：許多 JSON 函式庫允許以原生程式環境的物件成員方式，存取 JSON 物件成員。然而，# 雖然是合法的 JSON 成員名稱字元，在許多程式環境中卻不是合法的物件成員名稱字元。因此，實作需要使用其他存取形式。例如，在 JavaScript 中，以 var j = JSON.parse(json); 解析後，可用 j["client_name#en-us"] 存取 client_name#en-us 成員。

2.3. 軟體聲明

軟體聲明是一種 JSON Web Token（JWT）[RFC7519]，將用戶端軟體的中繼資料值整批作為宣告。第 2 節定義一組可用於軟體聲明的宣告。作為用戶端註冊請求的一部分提交給授權伺服器時，軟體聲明必須（MUST）使用 JSON Web Signature（JWS）[RFC7515] 進行數位簽章或 MAC 保護，且必須（MUST）包含 iss（issuer，簽發者）宣告，指出為聲明中各項宣告背書的對象。建議（RECOMMENDED）使用 RS256 簽章演算法進行數位簽章，但特定應用可以（MAY）指定其他演算法。建議（RECOMMENDED）軟體聲明包含 software_id 宣告，讓授權伺服器能將使用相同軟體聲明的不同軟體實例關聯起來。

例如，軟體聲明可以包含下列宣告：

{
 "software_id": "4NRB1-0XZABZI9E6-5SM3R",
 "client_name": "Example Statement-based Client",
 "client_uri": "https://client.example.net/"
}

以下非規範性 JWT 範例包含這些宣告，並以 RS256 進行非對稱簽章（換行僅供顯示）：

eyJhbGciOiJSUzI1NiJ9.
eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll
bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs
aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA

譯註：原文此非規範性 JWT 範例的 payload 未包含上文明定的 iss 宣告；此處保留原例，實作仍須遵守 iss 的必要要求。

軟體聲明通常會隨用戶端應用程式的所有實例一同散布。用戶端或開發者如何取得軟體聲明，不在本規範範圍內。常見方式可能包括：用戶端開發者向軟體 API 發布者註冊，取得適用於某類用戶端的軟體聲明，藉此產生用戶端專屬的 JWT。

授權伺服器用來判斷是否信任及使用軟體聲明資訊的準則，不在本規範範圍內。

某些情況下，授權伺服器可以（MAY）選擇直接接受授權請求中的軟體聲明值作為用戶端識別碼，而不先進行動態註冊。授權伺服器在什麼情況下會這麼做，以及此時所需的特定軟體聲明特性，不在本規範範圍內。

3. 用戶端註冊端點

用戶端註冊端點是本文件定義的 OAuth 2.0 端點，讓用戶端向授權伺服器註冊。此端點必須（MUST）接受 HTTP POST 訊息，請求參數以 application/json 格式編碼於實體主體中。此端點必須（MUST）依第 5 節所述，以傳輸層安全機制保護。

用戶端註冊端點可以（MAY）是 OAuth 2.0 [RFC6749] 受保護資源，也可以（MAY）接受 OAuth 2.0 存取權杖形式的初始存取權杖，將註冊限制為先前已獲授權的對象。用戶端或開發者取得初始存取權杖的方式通常在協定外進行，不在本規範範圍內。註冊端點如何驗證及確認此權杖有效，也不在本規範範圍內。

為支援開放註冊並促進更廣泛的互通性，用戶端註冊端點應（SHOULD）允許未經授權的註冊請求，也就是請求中沒有初始存取權杖。這類請求可以（MAY）受到速率限制或其他限制，以防止針對註冊端點的阻斷服務攻擊。

3.1. 用戶端註冊請求

此操作向授權伺服器註冊用戶端。授權伺服器為它指派唯一的用戶端識別碼、選擇性地指派用戶端密鑰，並將請求提供的中繼資料與簽發的識別碼關聯。請求包含註冊時為用戶端指定的各項中繼資料參數。對於省略的項目，授權伺服器可以（MAY）配置預設值。

註冊時，用戶端或開發者向註冊端點傳送內容類型為 application/json 的 HTTP POST。HTTP 實體負載是由一個 JSON 物件構成的 JSON [RFC7159] 文件，所有請求的用戶端中繼資料值都放在該物件的頂層成員中。

例如，若伺服器支援開放註冊（不需初始存取權杖），用戶端可以向註冊端點傳送以下請求。這是不使用初始存取權杖的非規範性範例：

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com

{
 "redirect_uris": [
   "https://client.example.org/callback",
   "https://client.example.org/callback2"],
 "client_name": "My Example Client",
 "client_name#ja-Jpan-JP":
    "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "token_endpoint_auth_method": "client_secret_basic",
 "logo_uri": "https://client.example.org/logo.png",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "example_extension_parameter": "example_value"
}

另一種情況是伺服器支援經授權的註冊，並向開發者或用戶端提供初始存取權杖。（如何取得此權杖，不在本規範範圍內。）開發者或用戶端會向註冊端點傳送以下經授權的請求。此例以 OAuth 2.0 Bearer Token [RFC6750] 傳送初始存取權杖，但授權伺服器也可以使用任何 OAuth 2.0 權杖類型。

以下是使用初始存取權杖，並直接以值註冊 JWK Set 的非規範性範例（值內換行僅供顯示）：

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Authorization: Bearer ey23f2.adfj230.af32-developer321
Host: server.example.com

{
 "redirect_uris": ["https://client.example.org/callback",
    "https://client.example.org/callback2"],
 "client_name": "My Example Client",
 "client_name#ja-Jpan-JP":
    "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "token_endpoint_auth_method": "client_secret_basic",
 "policy_uri": "https://client.example.org/policy.html",
 "jwks": {"keys": [{
    "e": "AQAB",
    "n": "nj3YJwsLUFl9BmpAbkOswCNVx17Eh9wMO-_AReZwBqfaWFcfG
HrZXsIV2VMCNVNU8Tpb4obUaSXcRcQ-VMsfQPJm9IzgtRdAY8NN8Xb7PEcYyk
lBjvTtuPbpzIaqyiUepzUXNDFuAOOkrIol3WmflPUUgMKULBN0EUd1fpOD70p
RM0rlp_gg_WNUKoW1V-3keYUJoXH9NztEDm_D2MQXj9eGOJJ8yPgGL8PAZMLe
2R7jb9TxOCPDED7tY_TU4nFPlxptw59A42mldEmViXsKQt60s1SLboazxFKve
qXC_jpLUt22OC6GUG63p-REw-ZOr3r845z50wMuzifQrMI9bQ",
    "kty": "RSA"
 }]},
 "example_extension_parameter": "example_value"
}

3.1.1. 使用軟體聲明的用戶端註冊請求

除了 JSON 元素之外，用戶端中繼資料值也可以（MAY）透過第 2.3 節所述的軟體聲明提供。若授權伺服器不支援此功能，可以（MAY）忽略軟體聲明。若支援，則必須（MUST）優先採用軟體聲明傳遞的中繼資料值，而非一般 JSON 元素中的值。

使用下列選用（OPTIONAL）成員，將軟體聲明放入請求的 JSON 物件：

software_statement：以宣告形式包含用戶端軟體中繼資料值的軟體聲明。其型別為字串，包含完整的已簽章 JWT。

以下範例中，部分註冊參數透過第 2.3 節範例的軟體聲明傳遞，部分用戶端實例專屬的值則以一般參數傳遞（值內換行僅供顯示）：

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com

{
  "redirect_uris": [
    "https://client.example.org/callback",
    "https://client.example.org/callback2"
  ],
  "software_statement": "eyJhbGciOiJSUzI1NiJ9.
eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll
bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs
aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA",
  "scope": "read write",
  "example_extension_parameter": "example_value"
}

3.2. 回應

註冊請求成功時，授權伺服器傳回用戶端識別碼。伺服器以 HTTP 201 Created 狀態碼回應，主體類型為 application/json，內容如第 3.2.1 節所述。

註冊請求失敗時，授權伺服器依第 3.2.2 節傳回錯誤。

3.2.1. 用戶端資訊回應

回應包含用戶端識別碼；若為機密用戶端，也包含用戶端密鑰。回應可以（MAY）包含本規範擴充所定義的其他欄位。

client_id：必要（REQUIRED）。OAuth 2.0 用戶端識別碼字串。它不應（SHOULD NOT）是任何其他已註冊用戶端目前有效的識別碼；不過，授權伺服器可以（MAY）自行決定，向同一已註冊用戶端的多個實例簽發相同識別碼。

client_secret：選用（OPTIONAL）。OAuth 2.0 用戶端密鑰字串。若簽發，每個 client_id 的密鑰必須（MUST）唯一，使用相同 client_id 的多個用戶端實例之間也應（SHOULD）具有不同密鑰。機密用戶端使用此值向權杖端點驗證身分，如 OAuth 2.0 [RFC6749] 第 2.3.1 節所述。

client_id_issued_at：選用（OPTIONAL）。用戶端識別碼的簽發時間，以 UTC 計算，自 1970-01-01T00:00:00Z 起至簽發日期時間的秒數表示。

client_secret_expires_at：若簽發 client_secret，此欄位為必要（REQUIRED）。表示用戶端密鑰到期時間；若永不到期，則為 0。時間以 UTC 計算，自 1970-01-01T00:00:00Z 起至到期日期時間的秒數表示。

此外，授權伺服器必須（MUST）傳回該用戶端的所有已註冊中繼資料，包括授權伺服器自行配置的欄位。授權伺服器可以（MAY）拒絕或取代註冊時用戶端請求的任何中繼資料值，並代入合適的值。用戶端或開發者可檢查回應值，判斷註冊結果是否足以使用，例如已註冊的 token_endpoint_auth_method 是否受用戶端軟體支援，並決定適當的後續處置。如何回應這種情況，不在本規範範圍內；可能的作法包括向應用程式開發者或授權伺服器提供者回報、以不同中繼資料重新註冊，或其他方法。例如，若伺服器支援 [RFC7592] 等註冊管理機制，用戶端或開發者可以嘗試以不同中繼資料更新註冊。也可以使用 [OpenID.Discovery] 等服務探索協定列出伺服器能力，協助用戶端提出資訊更充分的註冊請求。使用任何此類管理或探索系統皆為選用，且不在本規範範圍內。

成功的註冊回應使用 HTTP 201 Created，主體類型為 application/json，由單一 JSON 物件 [RFC7159] 構成，所有參數都是該物件的頂層成員。

若註冊時使用軟體聲明，回應必須（MUST）以 software_statement 成員名稱，連同其他中繼資料原樣傳回其值。從軟體聲明採用的用戶端中繼資料元素，也必須（MUST）在註冊回應中直接作為頂層中繼資料值傳回；其值可能不同，因為請求值與實際使用值可能有所差異。

以下是註冊成功的非規範性回應範例：

HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "client_id": "s6BhdRkqt3",
 "client_secret": "cf136dc3c1fc93f31185e5885805d",
 "client_id_issued_at": 2893256800,
 "client_secret_expires_at": 2893276800,
 "redirect_uris": [
   "https://client.example.org/callback",
   "https://client.example.org/callback2"],
 "grant_types": ["authorization_code", "refresh_token"],
 "client_name": "My Example Client",
 "client_name#ja-Jpan-JP":
    "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "token_endpoint_auth_method": "client_secret_basic",
 "logo_uri": "https://client.example.org/logo.png",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "example_extension_parameter": "example_value"
}

3.2.2. 用戶端註冊錯誤回應

若發生 OAuth 2.0 錯誤，例如用戶端提交無效的初始存取權杖，授權伺服器會傳回適用於該 OAuth 2.0 權杖類型的錯誤回應。

若發生註冊錯誤，除非另有規定，授權伺服器傳回 HTTP 400 狀態碼，內容類型為 application/json，回應主體由描述錯誤的 JSON 物件 [RFC7159] 構成。

JSON 物件定義以下兩個成員：

  • error：必要（REQUIRED）。單一 ASCII 錯誤代碼字串。
  • error_description：選用（OPTIONAL）。供人閱讀、用於除錯的 ASCII 錯誤說明文字。

也可以（MAY）包含其他成員；不理解的成員必須（MUST）忽略。

本規範定義以下錯誤代碼：

  • invalid_redirect_uri：一個或多個重新導向 URI 值無效。
  • invalid_client_metadata：某個用戶端中繼資料欄位值無效，且伺服器已拒絕此請求。請注意，授權伺服器可以（MAY）選擇以有效值取代用戶端中繼資料中任何請求參數。
  • invalid_software_statement：提交的軟體聲明無效。
  • unapproved_software_statement：提交的軟體聲明未獲此授權伺服器核准使用。

以下非規範性錯誤回應範例，是因重新導向 URI 被授權伺服器列入黑名單而產生（值內換行僅供顯示）：

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "error": "invalid_redirect_uri",
 "error_description": "The redirection URI
   http://sketchy.example.com is not allowed by this server."
}

以下非規範性錯誤回應範例，是因 response_types 與 grant_types 的組合不一致而產生（值內換行僅供顯示）：

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "error": "invalid_client_metadata",
 "error_description": "The grant type 'authorization_code' must be
   registered along with the response type 'code' but found only
  'implicit' instead."
}

4. IANA 考量

4.1. OAuth 動態用戶端註冊中繼資料登錄表

本規範建立「OAuth Dynamic Client Registration Metadata」登錄表。

OAuth 註冊用戶端中繼資料的名稱與描述，採「需要規範」（Specification Required，[RFC5226]）政策登錄，須在 oauth-ext-review@ietf.org 郵件論壇經過兩週審查，並依一位或多位指定專家（Designated Experts）的建議辦理。不過，為允許在文件發布前分配名稱，指定專家若確信相關規範將會發布，可以依 [RFC7120] 預先核准登錄。

送至郵件論壇審查的登錄請求，應使用適當主旨，例如「Request to register OAuth Dynamic Client Registration Metadata name: example」。

指定專家會在審查期間核准或否決登錄請求，並將決定通知審查論壇與 IANA。否決時應附說明，以及適用時可使請求獲准的修改建議。

IANA 只能接受指定專家提交的登錄表更新，並應將所有登錄請求導向審查郵件論壇。

4.1.1. 登錄範本

用戶端中繼資料名稱（Client Metadata Name）：所請求的名稱，例如 example。名稱區分大小寫。不應（SHOULD NOT）接受與其他已登錄名稱僅大小寫不同的名稱。

用戶端中繼資料描述（Client Metadata Description）：簡述中繼資料值，例如「範例說明」。

變更管理者（Change Controller）：標準軌 RFC 填寫 IESG；其他文件則填寫負責方名稱。也可包含郵寄地址、電子郵件地址、首頁 URI 等其他資訊。

規範文件（Specification Document(s)）：定義該用戶端中繼資料的一份或多份文件參照，最好包含可取得文件副本的 URI。也可以註明相關章節，但非必要。

4.1.2. 初始登錄內容

「OAuth Dynamic Client Registration Metadata」登錄表的初始內容如下。每項的變更管理者皆為 IESG，規範文件皆為 RFC 7591。

用戶端中繼資料名稱 用戶端中繼資料描述
redirect_uris 供重新導向流程使用的重新導向 URI 陣列
token_endpoint_auth_method 所請求的權杖端點驗證方法
grant_types 用戶端可以使用的 OAuth 2.0 授予類型陣列
response_types 用戶端可以使用的 OAuth 2.0 回應類型陣列
client_name 向使用者呈現、供人閱讀的用戶端名稱
client_uri 提供用戶端資訊之網頁的 URL
logo_uri 指向用戶端標誌的 URL
scope 以空格分隔的 OAuth 2.0 範圍值清單
contacts 表示用戶端負責人聯絡方式的字串陣列，通常為電子郵件地址
tos_uri 指向供人閱讀之用戶端服務條款文件的 URL
policy_uri 指向供人閱讀之用戶端政策文件的 URL
jwks_uri 指向表示用戶端公開金鑰之 JSON Web Key Set [RFC7517] 文件的 URL
jwks 表示用戶端公開金鑰的 JSON Web Key Set [RFC7517] 文件
software_id 構成用戶端之軟體的識別碼
software_version 構成用戶端之軟體的版本識別碼
client_id 用戶端識別碼
client_secret 用戶端密鑰
client_id_issued_at 用戶端識別碼的簽發時間
client_secret_expires_at 用戶端密鑰的到期時間

4.2. OAuth 權杖端點驗證方法登錄表

本規範建立「OAuth Token Endpoint Authentication Methods」登錄表。

供 token_endpoint_auth_method 使用的其他值，採「需要規範」（Specification Required，[RFC5226]）政策登錄，須在 oauth-ext-review@ietf.org 郵件論壇經過兩週審查，並依一位或多位指定專家的建議辦理。不過，為允許在文件發布前分配值，指定專家若確信相關規範將會發布，可以依 [RFC7120] 預先核准登錄。

登錄請求必須送至 oauth-ext-review@ietf.org 郵件論壇供審查與評論，並使用適當主旨，例如「Request to register token_endpoint_auth_method value: example」。

指定專家會在審查期間核准或否決登錄請求，並將決定通知審查論壇與 IANA。否決時應附說明，以及適用時可使請求獲准的修改建議。

IANA 只能接受指定專家提交的登錄表更新，並應將所有登錄請求導向審查郵件論壇。

4.2.1. 登錄範本

權杖端點驗證方法名稱（Token Endpoint Authentication Method Name）：所請求的名稱，例如 example。名稱區分大小寫。不應（SHOULD NOT）接受與其他已登錄名稱僅大小寫不同的名稱。

變更管理者（Change Controller）：標準軌 RFC 填寫 IESG；其他文件則填寫負責方名稱。也可包含郵寄地址、電子郵件地址、首頁 URI 等其他資訊。

規範文件（Specification Document(s)）：定義該權杖端點驗證方法的一份或多份文件參照，最好包含可取得文件副本的 URI。也可以註明相關章節，但非必要。

4.2.2. 初始登錄內容

「OAuth Token Endpoint Authentication Methods」登錄表的初始內容如下：

權杖端點驗證方法名稱 變更管理者 規範文件
none IESG RFC 7591
client_secret_post IESG RFC 7591
client_secret_basic IESG RFC 7591

5. 安全性考量

由於對用戶端註冊端點的請求會在 HTTP 請求與回應中傳送明文憑證，授權伺服器必須（MUST）要求向註冊端點發送請求時使用傳輸層安全機制。伺服器必須（MUST）支援 TLS 1.2 [RFC5246]，也可以（MAY）支援符合其安全要求的其他傳輸層安全機制。使用 TLS 時，用戶端必須（MUST）依 RFC 6125 [RFC6125] 檢查 TLS/SSL 伺服器憑證。實作安全考量可見《安全使用 TLS 與 DTLS 的建議》[BCP195]。

對於使用 authorization_code、implicit 等重新導向授予類型的用戶端，授權伺服器必須（MUST）要求它們註冊重新導向 URI 值。這有助於減輕惡意行為者冒充合法已註冊用戶端，並透過無效的重新導向 URI 或開放重新導向器攔截授權碼或權杖的攻擊。此外，為防止重新導向的傳回值遭挾持，已註冊的重新導向 URI 值必須（MUST）屬於以下其中一種：

  • 受 TLS 保護的遠端網站，例如 https://client.example.com/oauth_redirect。
  • 使用 HTTP URI、託管於本機的網站，例如 http://localhost:8080/oauth_redirect。
  • 僅供該用戶端應用程式使用、非 HTTP 的應用程式專屬 URL，例如 exampleapp://oauth_redirect。

若授權伺服器政策允許，公開用戶端可以（MAY）透過本協定註冊。公開用戶端的 token_endpoint_auth_method 中繼資料欄位使用 none，且通常搭配 implicit 授予類型。這些用戶端往往是生命週期短暫的瀏覽器內應用程式，請求存取使用者資源，其存取權與使用者在授權伺服器上的有效工作階段相連。由於它們通常沒有長期儲存空間，可能每次載入瀏覽器應用程式時都需要重新註冊。為避免產生大量不再使用的用戶端識別碼，授權伺服器可以（MAY）決定，在經過一段時間後，讓符合特定條件的既有用戶端註冊到期。另一種方式是在提供瀏覽器應用程式程式碼的伺服器上註冊用戶端，再將用戶端組態連同程式碼一起傳送至瀏覽器。

由於不同 OAuth 2.0 授予類型具有不同的安全與使用特性，授權伺服器可以（MAY）要求同一軟體為不同授予類型分別註冊。例如，授權伺服器可能要求所有使用 authorization_code 的用戶端，在 token_endpoint_auth_method 中採用用戶端密鑰，但要求所有使用 implicit 的用戶端在權杖端點不使用任何驗證。在這種情況下，伺服器可以（MAY）禁止用戶端同時註冊 authorization_code 與 implicit。同樣地，authorization_code 表示代表終端使用者存取，client_credentials 則表示代表用戶端本身存取。基於安全理由，授權伺服器可以要求這兩種情況使用不同範圍，因此可以（MAY）禁止同一用戶端同時註冊這兩種授予類型。在所有這些情況下，授權伺服器都會傳回 invalid_client_metadata 錯誤。

除非中繼資料是作為軟體聲明中的宣告使用，授權伺服器必須（MUST）將所有用戶端中繼資料視為自行宣告。例如，惡意用戶端可能使用它試圖冒充之合法用戶端的名稱與標誌，也可能使用合法用戶端的軟體識別碼或軟體版本，企圖在授權伺服器上將自己與合法實例關聯。為防範此事，授權伺服器必須（MUST）檢視完整註冊請求與用戶端組態，採取適當措施減輕風險。例如，標誌的網域／網站若與重新導向 URI 的網域／網站不符，可以發出警告。授權伺服器也可以拒絕使用已知軟體識別碼，卻請求不同重新導向 URI 或用戶端 URI 的註冊請求。授權伺服器也可以對所有動態註冊用戶端向終端使用者顯示警告，尤其是剛註冊、或尚未被該伺服器任何使用者信任的用戶端。

授權伺服器若支援開放用戶端註冊，對於用戶端提供、且將顯示給使用者的 URL，例如 logo_uri、tos_uri、client_uri、policy_uri，必須格外謹慎。例如，惡意用戶端可能在註冊請求的 policy_uri 指向惡意自動下載內容，誘使使用者在授權時點擊。授權伺服器應（SHOULD）檢查這四種 URI 是否與 redirect_uris 陣列中的 URI 具有相同主機及配置（scheme），並確認這些 URI 均可解析到有效網頁。由於這些 URI 值預期會在授權頁面顯示給使用者，授權伺服器應（SHOULD）盡可能保護使用者，避免接觸 URL 託管的惡意內容。例如，可在授權頁面呈現 URL 前，下載其內容並以惡意軟體掃描器及黑名單過濾器檢查、確認是否混用安全與不安全內容，以及採取其他伺服器端緩解措施。請注意，URL 內容隨時可能變更，授權伺服器無法完全保證其安全，但這些作法仍可能有所幫助。為進一步減輕這類威脅，授權伺服器也可以警告使用者：這些 URL 由第三方提供，應謹慎對待，並非由授權伺服器本身託管。例如，不直接在 HTML 連結中提供目標 URL，而是先將使用者導向警告中介頁，再允許前往目標 URL。

用戶端可以（MAY）在註冊請求中，同時透過直接的 JSON 物件及 JWT 編碼的軟體聲明，向授權伺服器提供中繼資料。軟體聲明受到密碼學保護，代表聲明簽發者所作的宣告；JSON 物件則代表用戶端或開發者直接自行提出的宣告。若軟體聲明有效，且由可接受的權威方（例如軟體 API 發布者）簽署，則必須（MUST）優先採用聲明內的用戶端中繼資料值，而非可能遭攔截及修改的一般 JSON 物件中的值。

與所有中繼資料值一樣，即使內容已經由簽發者以數位簽章或 MAC 保護，提交軟體聲明這件事仍然是由用戶端自行宣稱。因此，在多數情況下，僅出示軟體聲明並不足以完整識別某個用戶端軟體。相較之下，初始存取權杖不一定包含某個特定用戶端軟體的資訊，而是代表使用註冊端點的授權。授權伺服器在決定是否接受註冊請求時，必須（MUST）考慮完整請求，包括軟體聲明、初始存取權杖及 JSON 用戶端中繼資料值。

若授權伺服器收到某個用戶端的註冊請求，而該用戶端原本不預期同時註冊多個實例，且伺服器可推知這是重複註冊，例如與既有用戶端具有相同 software_id 及 software_version，伺服器應（SHOULD）將新註冊視為可疑並予以拒絕。新用戶端可能試圖冒充既有用戶端，誘騙使用者授權，也可能是原本註冊已不再有效。如何處理取決於授權伺服器的部署，不在本規範範圍內。

由於用戶端識別碼是公開值，可在授權端點用來冒充用戶端，授權伺服器若決定向某個已註冊用戶端的多個實例簽發相同識別碼，就必須非常審慎地決定適用情況。例如，可以將同一識別碼限於使用相同重新導向流程及相同重新導向 URI 的用戶端。即使簽發相同識別碼，授權伺服器也不應（SHOULD NOT）向同一已註冊用戶端的多個實例簽發相同用戶端密鑰，否則密鑰可能外洩，讓惡意冒充者得以冒充機密用戶端。

6. 隱私考量

本規範描述的協定幾乎只處理軟體資訊，而非人的資訊，因此使用時的隱私疑慮很少。值得注意的例外是第 2 節定義的 contacts 欄位，其中包含開發者或其他用戶端軟體負責人的聯絡資訊。這些值預期會顯示給終端使用者，授權伺服器管理員也能取得。因此，開發者可能希望提供專供用戶端支援使用的電子郵件地址或其他聯絡方式，而非私人或工作地址。另一種方式是提供用戶端的共用電子郵件地址，讓開發者離開、由他人接手責任後，仍可持續聯絡及支援該軟體。

一般而言，用戶端名稱、軟體識別碼等中繼資料，在同一軟體的所有實例之間共通，因此不會對終端使用者造成隱私問題。另一方面，用戶端識別碼往往是特定實例所獨有。對許多人共同使用的網站等用戶端，識別碼可能不會造成顯著隱私疑慮；但對安裝在單一終端使用者裝置上的原生應用程式等用戶端，識別碼可能在 OAuth 2.0 交易過程中被唯一追蹤，並將其使用情形與該使用者相連。不過，由於用戶端軟體仍須透過 OAuth 2.0 授權授予獲得資源擁有者授權，即使識別碼並非唯一，也可以將已驗證的資源擁有者與提出請求的用戶端識別碼關聯，進行這種追蹤。

請注意，本規範禁止用戶端自行建立用戶端識別碼。若允許，單一實例就可能在多個串通的授權伺服器之間被追蹤，產生隱私及安全問題。此外，即使是同一軟體實例，每次註冊請求通常也會取得不同的識別碼。如此一來，應用程式可透過多次註冊，呈現為完全獨立的應用程式，略微改善隱私。不過，此方式會要求每位資源擁有者進行多次授權，造成顯著的易用性成本，因此實務上不太可能採用。

7. 參考資料

譯註：參考資料保留原始作者、英文題名、日期與識別資訊，以利查找；連結改用 HTTPS。這些是原文發布時引用的版本。

7.1. 規範性參考資料

  • [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”, BCP 195, RFC 7525, May 2015. 文件
  • [IANA.Language] IANA, “Language Subtag Registry”. 登錄表
  • [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. 文件
  • [RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008. 文件
  • [RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008. 文件
  • [RFC5646] Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages”, BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009. 文件
  • [RFC6125] Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)”, RFC 6125, DOI 10.17487/RFC6125, March 2011. 文件
  • [RFC6749] Hardt, D., Ed., “The OAuth 2.0 Authorization Framework”, RFC 6749, DOI 10.17487/RFC6749, October 2012. 文件
  • [RFC6750] Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage”, RFC 6750, DOI 10.17487/RFC6750, October 2012. 文件
  • [RFC7120] Cotton, M., “Early IANA Allocation of Standards Track Code Points”, BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014. 文件
  • [RFC7159] Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format”, RFC 7159, DOI 10.17487/RFC7159, March 2014. 文件
  • [RFC7515] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS)”, RFC 7515, DOI 10.17487/RFC7515, May 2015. 文件
  • [RFC7517] Jones, M., “JSON Web Key (JWK)”, RFC 7517, DOI 10.17487/RFC7517, May 2015. 文件
  • [RFC7519] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT)”, RFC 7519, DOI 10.17487/RFC7519, May 2015. 文件
  • [RFC7522] Campbell, B., Mortimore, C., and M. Jones, “Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants”, RFC 7522, DOI 10.17487/RFC7522, May 2015. 文件
  • [RFC7523] Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants”, RFC 7523, DOI 10.17487/RFC7523, May 2015. 文件

7.2. 資訊性參考資料

  • [OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0”, November 2014. 文件
  • [OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0”, November 2014. 文件
  • [RFC7592] Richer, J., Jones, M., Bradley, J., and M. Machulak, “OAuth 2.0 Dynamic Client Registration Management Protocol”, RFC 7592, DOI 10.17487/RFC7592, July 2015. 文件
  • [UMA-Core] Hardjono, T., Maler, E., Machulak, M., and D. Catalano, “User-Managed Access (UMA) Profile of OAuth 2.0”, Work in Progress, draft-hardjono-oauth-umacore-13, April 2015. 草案

附錄 A. 使用案例

本附錄描述本規範的不同使用方式，以及可能需要作出的選擇。有些選擇彼此獨立、可以組合使用，有些則相互關聯。

A.1. 開放與受保護的動態用戶端註冊

A.1.1. 開放動態用戶端註冊

支援開放註冊的授權伺服器，允許不使用初始存取權杖進行註冊。這讓所有用戶端軟體都能向授權伺服器註冊。

A.1.2. 受保護的動態用戶端註冊

支援受保護註冊的授權伺服器，要求註冊請求使用初始存取權杖。用戶端或開發者如何取得、授權伺服器如何驗證此權杖，雖然不在本規範範圍內，但常見作法是開發者透過授權伺服器的人工預先註冊入口，取得簽發給開發者的初始存取權杖。

A.2. 不使用或使用軟體聲明的註冊

A.2.1. 不使用軟體聲明的註冊

註冊請求未使用軟體聲明時，授權伺服器必須願意使用未經任何權威方數位簽章或 MAC 保護、因而也未獲其背書的用戶端中繼資料值。（請注意，這項選擇獨立於開放或受保護註冊的選擇；初始存取權杖是另一種可能的背書形式。）

A.2.2. 使用軟體聲明的註冊

註冊請求可以使用軟體聲明，為一組用戶端中繼資料值提供權威方背書。當授權伺服器希望將註冊限於一組權威方背書的用戶端軟體，或希望知道多個註冊請求是否指向同一軟體時，這會有所幫助。

A.3. 由用戶端或開發者註冊

A.3.1. 由用戶端註冊

某些使用案例中，用戶端軟體會動態向授權伺服器自行註冊，取得用戶端識別碼及與授權伺服器互動所需的其他資訊。在此情況下，用戶端軟體不會預先封裝適用於該授權伺服器的識別碼。

A.3.2. 由開發者註冊

某些情況下，開發者或其使用的開發軟體，會向一個或一組授權伺服器預先註冊用戶端軟體。在此情況下，這些授權伺服器的用戶端識別碼值可以隨軟體一同封裝。

A.4. 每個用戶端實例或每套用戶端軟體的用戶端 ID

A.4.1. 每個用戶端軟體實例各自使用 ID

某些情況下，用戶端軟體的每個已部署實例都會動態註冊，取得不同識別碼。例如，使用授權碼流程時，這樣也讓每個實例能有自己的用戶端密鑰，因此可能有利。這對原生用戶端可能有所幫助：它們無法確保隨軟體封裝的共用密鑰保密，卻可能有能力保護各實例專屬的密鑰。

A.4.2. 用戶端軟體的所有實例共用 ID

某些情況下，用戶端軟體的每個已部署實例會共用同一識別碼。例如，不涉及用戶端密鑰、使用隱式流程的瀏覽器內用戶端，往往如此。特定授權伺服器可能選擇維護軟體聲明值與用戶端識別碼值之間的對應，並對同一軟體的所有註冊請求傳回相同識別碼。授權伺服器何時會這麼做，以及此時所需的特定軟體聲明特性，不在本規範範圍內。

A.5. 有狀態或無狀態註冊

A.5.1. 有狀態用戶端註冊

某些情況下，授權伺服器會保存已註冊用戶端的狀態，通常以用戶端識別碼作為索引。狀態通常包含與註冊相關聯的中繼資料值，也可能包含授權伺服器實作專屬的其他狀態。採用有狀態註冊時，可以支援擷取及／或更新狀態的操作。[RFC7592] 描述了其中一組可能的操作。

A.5.2. 無狀態用戶端註冊

某些情況下，授權伺服器的實作可以不在本機保存任何已註冊用戶端狀態。一種作法是將所有註冊狀態編碼在傳回的用戶端識別碼值中，並可能以只有授權伺服器能解讀的方式加密，以維持狀態的機密性與完整性。

致謝

作者感謝 OAuth 工作小組、User-Managed Access 工作小組及 OpenID Connect 工作小組參與者對本文件提供意見。以下人士對本文件多個草案版本的審查及貢獻尤其重要：Amanda Anganes、Derek Atkins、Tim Bray、Domenico Catalano、Donald Coffin、Vladimir Dzhuvinov、George Fletcher、Thomas Hardjono、William Kim、Torsten Lodderstedt、Eve Maler、Josh Mandel、Nov Matake、Tony Nadalin、Nat Sakimura、Christian Scholz 及 Hannes Tschofenig。

作者聯絡資訊

以下為原文發布時的聯絡資訊：

  • Justin Richer（編輯）：電子郵件 ietf@justin.richer.org。
  • Michael B. Jones，Microsoft：電子郵件 mbj@microsoft.com；個人網站。
  • John Bradley，Ping Identity：電子郵件 ve7jtb@ve7jtb.com。
  • Maciej Machulak，Newcastle University：電子郵件 maciej.machulak@gmail.com。
  • Phil Hunt，Oracle Corporation：電子郵件 phil.hunt@yahoo.com。