Internet Engineering Task Force (IETF) J. Richer, Ed.
Request for Comments: 7591
Category: Standards Track M. Jones
ISSN: 2070-1721 Microsoft
J. Bradley
Ping Identity
M. Machulak
Newcastle University
P. Hunt
Oracle Corporation
July 2015
Internet Engineering Task Force (IETF) J. Richer, Ed.
Request for Comments: 7591
Category: Standards Track M. Jones
ISSN: 2070-1721 Microsoft
J. Bradley
Ping Identity
M. Machulak
Newcastle University
P. Hunt
Oracle Corporation
July 2015
OAuth 2.0 Dynamic Client Registration Protocol
OAuth 2.0动态客户端注册协议
Abstract
摘要
This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration.
本规范定义了用于向授权服务器动态注册OAuth 2.0客户端的机制。注册请求向授权服务器发送一组所需的客户端元数据值。生成的注册响应返回要在授权服务器上使用的客户端标识符以及为客户端注册的客户端元数据值。然后，客户机可以使用此注册信息使用OAuth 2.0协议与授权服务器通信。该规范还定义了一组通用的客户端元数据字段和值，供客户端在注册期间使用。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7591.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7591.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 7
2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Relationship between Grant Types and Response Types . . . 12
2.2. Human-Readable Client Metadata . . . . . . . . . . . . . 13
2.3. Software Statement . . . . . . . . . . . . . . . . . . . 14
3. Client Registration Endpoint . . . . . . . . . . . . . . . . 15
3.1. Client Registration Request . . . . . . . . . . . . . . . 16
3.1.1. Client Registration Request Using a Software
Statement . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1. Client Information Response . . . . . . . . . . . . . 19
3.2.2. Client Registration Error Response . . . . . . . . . 21
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
4.1. OAuth Dynamic Client Registration Metadata Registry . . . 22
4.1.1. Registration Template . . . . . . . . . . . . . . . . 24
4.1.2. Initial Registry Contents . . . . . . . . . . . . . . 24
4.2. OAuth Token Endpoint Authentication Methods Registry . . 27
4.2.1. Registration Template . . . . . . . . . . . . . . . . 28
4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Normative References . . . . . . . . . . . . . . . . . . 33
7.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 33
A.1. Open versus Protected Dynamic Client Registration . . . . 34
A.1.1. Open Dynamic Client Registration . . . . . . . . . . 34
A.1.2. Protected Dynamic Client Registration . . . . . . . . 34
A.2. Registration without or with Software Statements . . . . 34
A.2.1. Registration without a Software Statement . . . . . . 34
A.2.2. Registration with a Software Statement . . . . . . . 34
A.3. Registration by the Client or Developer . . . . . . . . . 34
A.3.1. Registration by the Client . . . . . . . . . . . . . 35
A.3.2. Registration by the Developer . . . . . . . . . . . . 35
A.4. Client ID per Client Instance or per Client Software . . 35
A.4.1. Client ID per Client Software Instance . . . . . . . 35
A.4.2. Client ID Shared among All Instances of Client
Software . . . . . . . . . . . . . . . . . . . . . . 35
A.5. Stateful or Stateless Registration . . . . . . . . . . . 35
A.5.1. Stateful Client Registration . . . . . . . . . . . . 36
A.5.2. Stateless Client Registration . . . . . . . . . . . . 36
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 7
2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Relationship between Grant Types and Response Types . . . 12
2.2. Human-Readable Client Metadata . . . . . . . . . . . . . 13
2.3. Software Statement . . . . . . . . . . . . . . . . . . . 14
3. Client Registration Endpoint . . . . . . . . . . . . . . . . 15
3.1. Client Registration Request . . . . . . . . . . . . . . . 16
3.1.1. Client Registration Request Using a Software
Statement . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1. Client Information Response . . . . . . . . . . . . . 19
3.2.2. Client Registration Error Response . . . . . . . . . 21
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
4.1. OAuth Dynamic Client Registration Metadata Registry . . . 22
4.1.1. Registration Template . . . . . . . . . . . . . . . . 24
4.1.2. Initial Registry Contents . . . . . . . . . . . . . . 24
4.2. OAuth Token Endpoint Authentication Methods Registry . . 27
4.2.1. Registration Template . . . . . . . . . . . . . . . . 28
4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Normative References . . . . . . . . . . . . . . . . . . 33
7.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 33
A.1. Open versus Protected Dynamic Client Registration . . . . 34
A.1.1. Open Dynamic Client Registration . . . . . . . . . . 34
A.1.2. Protected Dynamic Client Registration . . . . . . . . 34
A.2. Registration without or with Software Statements . . . . 34
A.2.1. Registration without a Software Statement . . . . . . 34
A.2.2. Registration with a Software Statement . . . . . . . 34
A.3. Registration by the Client or Developer . . . . . . . . . 34
A.3.1. Registration by the Client . . . . . . . . . . . . . 35
A.3.2. Registration by the Developer . . . . . . . . . . . . 35
A.4. Client ID per Client Instance or per Client Software . . 35
A.4.1. Client ID per Client Software Instance . . . . . . . 35
A.4.2. Client ID Shared among All Instances of Client
Software . . . . . . . . . . . . . . . . . . . . . . 35
A.5. Stateful or Stateless Registration . . . . . . . . . . . 35
A.5.1. Stateful Client Registration . . . . . . . . . . . . 36
A.5.2. Stateless Client Registration . . . . . . . . . . . . 36
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
In order for an OAuth 2.0 [RFC6749] client to utilize an OAuth 2.0 authorization server, the client needs specific information to interact with the server, including an OAuth 2.0 client identifier to use at that server. This specification describes how an OAuth 2.0 client can be dynamically registered with an authorization server to obtain this information.
为了使OAuth 2.0[RFC6749]客户机利用OAuth 2.0授权服务器，客户机需要与服务器交互的特定信息，包括在该服务器上使用的OAuth 2.0客户机标识符。本规范描述了如何在授权服务器上动态注册OAuth 2.0客户端以获取此信息。
As part of the registration process, this specification also defines a mechanism for the client to present the authorization server with a set of metadata, such as a set of valid redirection URIs. This metadata can either be communicated in a self-asserted fashion or as a set of metadata called a software statement, which is digitally signed or protected with a Message Authentication Code (MAC); in the case of a software statement, the issuer is vouching for the validity of the data about the client.
作为注册过程的一部分，此规范还定义了一种机制，用于客户端向授权服务器提供一组元数据，例如一组有效的重定向URI。该元数据可以以自断言的方式进行通信，也可以作为一组称为软件语句的元数据进行通信，该元数据通过消息认证码（MAC）进行数字签名或保护；在软件声明的情况下，发行人保证有关客户的数据的有效性。
Traditionally, registration of a client with an authorization server is performed manually. The mechanisms defined in this specification can be used either for a client to dynamically register itself with authorization servers or for a client developer to programmatically register the client with authorization servers. Multiple applications using OAuth 2.0 have previously developed mechanisms for accomplishing such registrations. This specification generalizes the registration mechanisms defined by "OpenID Connect Dynamic Client Registration 1.0" [OpenID.Registration] and used by "User Managed Access (UMA) Profile of OAuth 2.0" [UMA-Core] in a way that is compatible with both, while being applicable to a wider set of OAuth 2.0 use cases.
传统上，客户端与授权服务器的注册是手动执行的。本规范中定义的机制既可用于客户端向授权服务器动态注册自身，也可用于客户端开发人员以编程方式向授权服务器注册客户端。使用OAuth 2.0的多个应用程序以前已经开发了完成此类注册的机制。本规范概括了由“OpenID Connect Dynamic Client registration 1.0”[OpenID.registration]定义并由“OAuth 2.0的用户管理访问（UMA）配置文件”[UMA Core]使用的注册机制，其方式与两者兼容，同时适用于更广泛的OAuth 2.0用例集。
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
除非另有说明，否则所有协议参数名称和值都区分大小写。
This specification uses the terms "access token", "authorization code", "authorization endpoint", "authorization grant", "authorization server", "client", "client identifier", "client secret", "grant type", "protected resource", "redirection URI",
本规范使用术语“访问令牌”、“授权代码”、“授权端点”、“授权授予”、“授权服务器”、“客户端”、“客户端标识符”、“客户端机密”、“授权类型”、“受保护资源”、“重定向URI”，
"refresh token", "resource owner", "resource server", "response type", and "token endpoint" defined by OAuth 2.0 [RFC6749] and uses the term "Claim" defined by JSON Web Token (JWT) [RFC7519].
OAuth 2.0[RFC6749]定义的“刷新令牌”、“资源所有者”、“资源服务器”、“响应类型”和“令牌端点”，并使用JSON Web令牌（JWT）[RFC7519]定义的术语“声明”。
This specification defines the following terms:
本规范定义了以下术语：
Client Software Software implementing an OAuth 2.0 client.
客户端软件实现OAuth 2.0客户端的软件。
Client Instance A deployed instance of a piece of client software.
客户端实例客户端软件的已部署实例。
Client Developer The person or organization that builds a client software package and prepares it for distribution. At the time the client is built, the developer is often not aware of who the deploying service provider organizations will be. Client developers will need to use dynamic registration when they are unable to predict aspects of the software, such as the deployment URLs, at compile time. For instance, this can occur when the software API publisher and the deploying organization are not the same.
客户机开发人员构建客户机软件包并准备分发的人员或组织。在构建客户机时，开发人员通常不知道部署服务提供商组织将是谁。当客户端开发人员无法在编译时预测软件的某些方面（如部署URL）时，他们需要使用动态注册。例如，当软件API发布者和部署组织不同时，可能会发生这种情况。
Client Registration Endpoint OAuth 2.0 endpoint through which a client can be registered at an authorization server. The means by which the URL for this endpoint is obtained are out of scope for this specification.
客户端注册端点OAuth 2.0端点，通过该端点可以在授权服务器上注册客户端。获取此端点的URL的方法超出了本规范的范围。
Initial Access Token OAuth 2.0 access token optionally issued by an authorization server to a developer or client and used to authorize calls to the client registration endpoint. The type and format of this token are likely service specific and are out of scope for this specification. The means by which the authorization server issues this token as well as the means by which the registration endpoint validates this token are out of scope for this specification. Use of an initial access token is required when the authorization server limits the parties that can register a client.
初始访问令牌OAuth 2.0访问令牌，可由授权服务器向开发人员或客户机发出，用于授权对客户机注册端点的调用。此令牌的类型和格式可能是特定于服务的，不在本规范的范围内。授权服务器发布此令牌的方式以及注册端点验证此令牌的方式超出了本规范的范围。当授权服务器限制可以注册客户端的各方时，需要使用初始访问令牌。
Deployment Organization An administrative security domain under which a software API (service) is deployed and protected by an OAuth 2.0 framework. In some OAuth scenarios, the deployment organization and the software API publisher are the same. In these cases, the deploying organization will often have a close relationship with client software developers. In many other cases, the definer of the service may be an independent third-party publisher or a standards organization. When working to a published specification for an
部署组织一个管理安全域，在该域下部署软件API（服务），并受OAuth 2.0框架的保护。在某些OAuth场景中，部署组织和软件API发布者是相同的。在这些情况下，部署组织通常与客户端软件开发人员保持密切关系。在许多其他情况下，服务的定义者可能是独立的第三方发布者或标准组织。按照已发布的规范工作时
API, the client software developer is unable to have a prior relationship with the potentially many deployment organizations deploying the software API (service).
客户端软件开发人员无法与部署软件API（服务）的潜在多个部署组织建立事先关系。
Software API Deployment A deployed instance of a software API that is protected by OAuth 2.0 (a protected resource) in a particular deployment organization domain. For any particular software API, there may be one or more deployments. A software API deployment typically has an associated OAuth 2.0 authorization server as well as a client registration endpoint. The means by which endpoints are obtained are out of scope for this specification.
软件API部署特定部署组织域中受OAuth 2.0（受保护资源）保护的软件API的已部署实例。对于任何特定的软件API，可能有一个或多个部署。软件API部署通常具有关联的OAuth 2.0授权服务器以及客户端注册端点。获取端点的方法不在本规范的范围内。
Software API Publisher The organization that defines a particular web-accessible API that may be deployed in one or more deployment environments. A publisher may be any standards body, commercial, public, private, or open source organization that is responsible for publishing and distributing software and API specifications that may be protected via OAuth 2.0. In some cases, a software API publisher and a client developer may be the same organization. At the time of publication of a web-accessible API, the software publisher often does not have a prior relationship with the deploying organizations.
软件API发布者定义可在一个或多个部署环境中部署的特定web可访问API的组织。发布者可以是任何标准机构、商业、公共、私人或开源组织，负责发布和分发可能通过OAuth 2.0保护的软件和API规范。在某些情况下，软件API发布者和客户端开发人员可能是同一个组织。在发布可访问web的API时，软件发布者通常与部署组织没有事先的关系。
Software Statement A digitally signed or MACed JSON Web Token (JWT) [RFC7519] that asserts metadata values about the client software. In some cases, a software statement will be issued directly by the client developer. In other cases, a software statement will be issued by a third-party organization for use by the client developer. In both cases, the trust relationship the authorization server has with the issuer of the software statement is intended to be used as an input to the evaluation of whether the registration request is accepted. A software statement can be presented to an authorization server as part of a client registration request.
软件语句一种数字签名或标记的JSON Web令牌（JWT）[RFC7519]，用于断言有关客户端软件的元数据值。在某些情况下，客户开发人员将直接发布软件声明。在其他情况下，软件声明将由第三方组织发布，供客户开发人员使用。在这两种情况下，授权服务器与软件语句的颁发者之间的信任关系将用作评估注册请求是否被接受的输入。软件语句可以作为客户端注册请求的一部分呈现给授权服务器。
+--------(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 +---------------+
+-----------+
+--------(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 +---------------+
+-----------+
Figure 1: Abstract Dynamic Client Registration Flow
图1：抽象动态客户端注册流
The abstract OAuth 2.0 client dynamic registration flow illustrated in Figure 1 describes the interaction between the client or developer and the endpoint defined in this specification. This figure does not demonstrate error conditions. This flow includes the following steps:
图1所示的抽象OAuth 2.0客户端动态注册流描述了客户端或开发人员与本规范中定义的端点之间的交互。此图未显示错误情况。此流程包括以下步骤：
(A) Optionally, the client or developer is issued an initial access token giving access to the client registration endpoint. The method by which the initial access token is issued to the client or developer is out of scope for this specification.
（A） 可选地，向客户机或开发人员发出初始访问令牌，以允许访问客户机注册端点。向客户机或开发人员发出初始访问令牌的方法超出了本规范的范围。
(B) Optionally, the client or developer is issued a software statement for use with the client registration endpoint. The method by which the software statement is issued to the client or developer is out of scope for this specification.
（B） 或者，向客户机或开发人员发出软件语句，以用于客户机注册端点。向客户或开发人员发布软件语句的方法超出本规范的范围。
(C) The client or developer calls the client registration endpoint with the client's desired registration metadata, optionally including the initial access token from (A) if one is required by the authorization server.
（C） 客户机或开发人员使用客户机所需的注册元数据调用客户机注册端点，如果授权服务器需要，还可以选择从（A）中包含初始访问令牌。
(D) The authorization server registers the client and returns:
（D） 授权服务器注册客户端并返回：
* the client's registered metadata,
* 客户端的注册元数据，
* a client identifier that is unique at the server, and
* 在服务器上唯一的客户端标识符，以及
* a set of client credentials such as a client secret, if applicable for this client.
* 一组客户端凭据，如客户端机密（如果适用于此客户端）。
Examples of different configurations and usages are included in Appendix A.
附录A中包括了不同配置和用途的示例。
Registered clients have a set of metadata values associated with their client identifier at an authorization server, such as the list of valid redirection URIs or a display name.
已注册的客户端在授权服务器上具有一组与其客户端标识符关联的元数据值，例如有效重定向URI列表或显示名称。
These client metadata values are used in two ways:
这些客户端元数据值以两种方式使用：
o as input values to registration requests, and
o 作为注册请求的输入值，以及
o as output values in registration responses.
o 作为注册响应中的输出值。
The following client metadata fields are defined by this specification. The implementation and use of all client metadata fields is OPTIONAL, unless stated otherwise. All data member types (strings, arrays, numbers) are defined in terms of their JSON [RFC7159] representations.
以下客户端元数据字段由本规范定义。除非另有说明，否则所有客户端元数据字段的实现和使用都是可选的。所有数据成员类型（字符串、数组、数字）都是根据JSON[RFC7159]表示定义的。
redirect_uris Array of redirection URI strings for use in redirect-based flows such as the authorization code and implicit flows. As required by Section 2 of OAuth 2.0 [RFC6749], clients using flows with redirection MUST register their redirection URI values. Authorization servers that support dynamic registration for redirect-based flows MUST implement support for this metadata value.
重定向URI字符串的重定向URI数组，用于基于重定向的流，如授权代码和隐式流。按照OAuth 2.0[RFC6749]第2节的要求，使用重定向流的客户端必须注册其重定向URI值。支持基于重定向的流的动态注册的授权服务器必须实现对此元数据值的支持。
token_endpoint_auth_method String indicator of the requested authentication method for the token endpoint. Values defined by this specification are:
令牌\端点\身份验证\方法为令牌端点请求的身份验证方法的字符串指示符。本规范定义的值为：
* "none": The client is a public client as defined in OAuth 2.0, Section 2.1, and does not have a client secret.
* “无”：客户机是OAuth 2.0第2.1节中定义的公共客户机，没有客户机机密。
* "client_secret_post": The client uses the HTTP POST parameters as defined in OAuth 2.0, Section 2.3.1.
* “client_secret_post”：客户端使用OAuth 2.0第2.3.1节中定义的HTTP post参数。
* "client_secret_basic": The client uses HTTP Basic as defined in OAuth 2.0, Section 2.3.1.
* “client_secret_basic”：客户端使用OAuth 2.0第2.3.1节中定义的HTTP basic。
Additional values can be defined via the IANA "OAuth Token Endpoint Authentication Methods" registry established in Section 4.2. Absolute URIs can also be used as values for this parameter without being registered. If unspecified or omitted, the default is "client_secret_basic", denoting the HTTP Basic authentication scheme as specified in Section 2.3.1 of OAuth 2.0.
可以通过第4.2节中建立的IANA“OAuth令牌端点身份验证方法”注册表定义附加值。绝对URI也可以用作此参数的值，而无需注册。如果未指定或省略，默认值为“client_secret_basic”，表示OAuth 2.0第2.3.1节中指定的HTTP基本身份验证方案。
grant_types Array of OAuth 2.0 grant type strings that the client can use at the token endpoint. These grant types are defined as follows:
grant_types OAuth 2.0授权类型字符串的数组，客户端可以在令牌端点使用该字符串。这些补助金类型定义如下：
* "authorization_code": The authorization code grant type defined in OAuth 2.0, Section 4.1.
* “授权代码”：OAuth 2.0第4.1节中定义的授权代码授权类型。
* "implicit": The implicit grant type defined in OAuth 2.0, Section 4.2.
* “隐式”：OAuth 2.0第4.2节中定义的隐式授权类型。
* "password": The resource owner password credentials grant type defined in OAuth 2.0, Section 4.3.
* “密码”：OAuth 2.0第4.3节中定义的资源所有者密码凭据授予类型。
* "client_credentials": The client credentials grant type defined in OAuth 2.0, Section 4.4.
* “客户端凭据”：OAuth 2.0第4.4节中定义的客户端凭据授予类型。
* "refresh_token": The refresh token grant type defined in OAuth 2.0, Section 6.
* “刷新令牌”：OAuth 2.0第6节中定义的刷新令牌授权类型。
* "urn:ietf:params:oauth:grant-type:jwt-bearer": The JWT Bearer Token Grant Type defined in OAuth JWT Bearer Token Profiles [RFC7523].
* “urn:ietf:params:oauth:grant-type:jwt-bearer”：在oauth-jwt-bearer-Token配置文件[RFC7523]中定义的jwt-bearer-Token-grant-type。
* "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2.0 Bearer Assertion Grant defined in OAuth SAML 2 Bearer Token Profiles [RFC7522].
* “urn:ietf:params:oauth:grant-type:saml2-bearer”：在oauth SAML 2承载令牌配置文件[RFC7522]中定义的SAML 2.0承载断言授予。
If the token endpoint is used in the grant type, the value of this parameter MUST be the same as the value of the "grant_type" parameter passed to the token endpoint defined in the grant type definition. Authorization servers MAY allow for other values as defined in the grant type extension process described in OAuth 2.0, Section 4.5. If omitted, the default behavior is that the client will use only the "authorization_code" Grant Type.
如果在授予类型中使用令牌端点，则此参数的值必须与传递给在授予类型定义中定义的令牌端点的“grant_type”参数的值相同。授权服务器可以允许OAuth 2.0第4.5节中描述的授权类型扩展过程中定义的其他值。如果省略，默认行为是客户机将仅使用“authorization_code”授权类型。
response_types Array of the OAuth 2.0 response type strings that the client can use at the authorization endpoint. These response types are defined as follows:
客户端可在授权端点使用的OAuth 2.0响应类型字符串的响应类型数组。这些响应类型定义如下：
* "code": The authorization code response type defined in OAuth 2.0, Section 4.1.
* “代码”：OAuth 2.0第4.1节中定义的授权代码响应类型。
* "token": The implicit response type defined in OAuth 2.0, Section 4.2.
* “令牌”：OAuth 2.0第4.2节中定义的隐式响应类型。
If the authorization endpoint is used by the grant type, the value of this parameter MUST be the same as the value of the "response_type" parameter passed to the authorization endpoint defined in the grant type definition. Authorization servers MAY allow for other values as defined in the grant type extension process is described in OAuth 2.0, Section 4.5. If omitted, the default is that the client will use only the "code" response type.
如果授权类型使用授权端点，则此参数的值必须与传递给授权类型定义中定义的授权端点的“response_type”参数的值相同。授权服务器可以允许授权类型扩展过程中定义的其他值，如OAuth 2.0第4.5节所述。如果省略，默认情况下客户端将仅使用“代码”响应类型。
client_name Human-readable string name of the client to be presented to the end-user during authorization. If omitted, the authorization server MAY display the raw "client_id" value to the end-user instead. It is RECOMMENDED that clients always send this field. The value of this field MAY be internationalized, as described in Section 2.2.
client_name授权期间要呈现给最终用户的客户端的可读字符串名称。如果省略，授权服务器可能会向最终用户显示原始的“client_id”值。建议客户端始终发送此字段。如第2.2节所述，该字段的值可以国际化。
client_uri URL string of a web page providing information about the client. If present, the server SHOULD display this URL to the end-user in a clickable fashion. It is RECOMMENDED that clients always send this field. The value of this field MUST point to a valid web page. The value of this field MAY be internationalized, as described in Section 2.2.
客户端uri提供有关客户端信息的网页的URL字符串。如果存在，服务器应以可单击的方式向最终用户显示此URL。建议客户端始终发送此字段。此字段的值必须指向有效的网页。如第2.2节所述，该字段的值可以国际化。
logo_uri URL string that references a logo for the client. If present, the server SHOULD display this image to the end-user during approval. The value of this field MUST point to a valid image file. The value of this field MAY be internationalized, as described in Section 2.2.
logo_uri URL字符串，用于引用客户端的徽标。如果存在，服务器应在审批期间向最终用户显示此图像。此字段的值必须指向有效的图像文件。如第2.2节所述，该字段的值可以国际化。
scope String containing a space-separated list of scope values (as described in Section 3.3 of OAuth 2.0 [RFC6749]) that the client can use when requesting access tokens. The semantics of values in this list are service specific. If omitted, an authorization server MAY register a client with a default set of scopes.
范围字符串，包含范围值的空格分隔列表（如OAuth 2.0[RFC6749]第3.3节所述），客户端在请求访问令牌时可以使用该列表。此列表中的值的语义是特定于服务的。如果省略，授权服务器可以使用一组默认作用域注册客户端。
contacts Array of strings representing ways to contact people responsible for this client, typically email addresses. The authorization server MAY make these contact addresses available to end-users for support requests for the client. See Section 6 for information on Privacy Considerations.
contacts字符串数组，表示联系负责此客户端的人员的方式，通常是电子邮件地址。授权服务器可以将这些联系地址提供给最终用户，以供客户机的支持请求使用。有关隐私注意事项的信息，请参见第6节。
tos_uri URL string that points to a human-readable terms of service document for the client that describes a contractual relationship between the end-user and the client that the end-user accepts when authorizing the client. The authorization server SHOULD display this URL to the end-user if it is provided. The value of this field MUST point to a valid web page. The value of this field MAY be internationalized, as described in Section 2.2.
tos_uri URL字符串，指向用户可读的服务条款文档，用于描述最终用户和客户之间的合同关系，最终用户在授权客户时接受该关系。授权服务器应向最终用户显示此URL（如果提供）。此字段的值必须指向有效的网页。如第2.2节所述，该字段的值可以国际化。
policy_uri URL string that points to a human-readable privacy policy document that describes how the deployment organization collects, uses, retains, and discloses personal data. The authorization server SHOULD display this URL to the end-user if it is provided. The value of this field MUST point to a valid web page. The value of this field MAY be internationalized, as described in Section 2.2.
policy_uri URL字符串，指向人类可读的隐私策略文档，该文档描述部署组织如何收集、使用、保留和公开个人数据。授权服务器应向最终用户显示此URL（如果提供）。此字段的值必须指向有效的网页。如第2.2节所述，该字段的值可以国际化。
jwks_uri URL string referencing the client's JSON Web Key (JWK) Set [RFC7517] document, which contains the client's public keys. The value of this field MUST point to a valid JWK Set document. These keys can be used by higher-level protocols that use signing or encryption. For instance, these keys might be used by some applications for validating signed requests made to the token endpoint when using JWTs for client authentication [RFC7523]. Use of this parameter is preferred over the "jwks" parameter, as it allows for easier key rotation. The "jwks_uri" and "jwks" parameters MUST NOT both be present in the same request or response.
jwks_uri URL字符串，引用客户端的JSON Web密钥（JWK）集[RFC7517]文档，该文档包含客户端的公钥。此字段的值必须指向有效的JWK集文档。这些密钥可由使用签名或加密的高级协议使用。例如，当使用JWTs进行客户端身份验证时，一些应用程序可能会使用这些密钥来验证向令牌端点发出的签名请求[RFC7523]。与“jwks”参数相比，使用此参数更可取，因为它允许更轻松地旋转关键点。“jwks_uri”和“jwks”参数不能同时出现在同一请求或响应中。
jwks Client's JSON Web Key Set [RFC7517] document value, which contains the client's public keys. The value of this field MUST be a JSON object containing a valid JWK Set. These keys can be used by higher-level protocols that use signing or encryption. This parameter is intended to be used by clients that cannot use the "jwks_uri" parameter, such as native clients that cannot host public URLs. The "jwks_uri" and "jwks" parameters MUST NOT both be present in the same request or response.
jwks客户端的JSON Web密钥集[RFC7517]文档值，其中包含客户端的公钥。此字段的值必须是包含有效JWK集的JSON对象。这些密钥可由使用签名或加密的高级协议使用。此参数用于无法使用“jwks_uri”参数的客户端，例如无法承载公共URL的本机客户端。“jwks_uri”和“jwks”参数不能同时出现在同一请求或响应中。
software_id A unique identifier string (e.g., a Universally Unique Identifier (UUID)) assigned by the client developer or software publisher used by registration endpoints to identify the client software to be dynamically registered. Unlike "client_id", which is issued by the authorization server and SHOULD vary between instances, the "software_id" SHOULD remain the same for all instances of the client software. The "software_id" SHOULD remain the same across
软件标识由注册端点使用的客户端开发人员或软件发布者分配的唯一标识符字符串（例如，通用唯一标识符（UUID）），用于标识要动态注册的客户端软件。与“客户端id”不同，“客户端id”是由授权服务器发布的，并且在不同的实例之间应该有所不同，对于客户端软件的所有实例，“软件id”应该保持不变。整个系统的“软件id”应保持不变
multiple updates or versions of the same piece of software. The value of this field is not intended to be human readable and is usually opaque to the client and authorization server.
同一软件的多个更新或版本。此字段的值不是为了让人可读，并且对于客户端和授权服务器来说通常是不透明的。
software_version A version identifier string for the client software identified by "software_id". The value of the "software_version" SHOULD change on any update to the client software identified by the same "software_id". The value of this field is intended to be compared using string equality matching and no other comparison semantics are defined by this specification. The value of this field is outside the scope of this specification, but it is not intended to be human readable and is usually opaque to the client and authorization server. The definition of what constitutes an update to client software that would trigger a change to this value is specific to the software itself and is outside the scope of this specification.
软件版本由“软件id”标识的客户端软件的版本标识符字符串。“软件版本”的值应在对由相同“软件id”标识的客户端软件进行任何更新时更改。此字段的值旨在使用字符串相等匹配进行比较，本规范未定义其他比较语义。此字段的值不在本规范的范围内，但它不是供人阅读的，并且对客户端和授权服务器通常是不透明的。对客户端软件更新的定义（该更新将触发此值的更改）特定于软件本身，不在本规范的范围内。
Extensions and profiles of this specification can expand this list with metadata names and descriptions registered in accordance with the IANA Considerations in Section 4 of this document. The authorization server MUST ignore any client metadata sent by the client that it does not understand (for instance, by silently removing unknown metadata from the client's registration record during processing). The authorization server MAY reject any requested client metadata values by replacing requested values with suitable defaults as described in Section 3.2.1 or by returning an error response as described in Section 3.2.2.
本规范的扩展和概要文件可以扩展此列表，并根据本文件第4节中的IANA注意事项注册元数据名称和描述。授权服务器必须忽略客户端发送的它不理解的任何客户端元数据（例如，通过在处理过程中从客户端的注册记录中静默删除未知元数据）。授权服务器可通过使用第3.2.1节中所述的适当默认值替换请求的值，或通过返回第3.2.2节中所述的错误响应，拒绝任何请求的客户端元数据值。
Client metadata values can be either communicated directly in the body of a registration request, as described in Section 3.1, or included as claims in a software statement, as described in Section 2.3; a mixture of both is also possible. If the same client metadata name is present in both locations and the software statement is trusted by the authorization server, the value of a claim in the software statement MUST take precedence.
如第3.1节所述，客户机元数据值可以直接在注册请求正文中传递，也可以如第2.3节所述，作为声明包含在软件声明中；两者的混合也是可能的。如果两个位置都存在相同的客户端元数据名称，并且授权服务器信任该软件语句，则该软件语句中的声明值必须优先。
The "grant_types" and "response_types" values described above are partially orthogonal, as they refer to arguments passed to different endpoints in the OAuth protocol. However, they are related in that the "grant_types" available to a client influence the "response_types" that the client is allowed to use, and vice versa. For instance, a "grant_types" value that includes "authorization_code" implies a "response_types" value that includes "code", as both values are defined as part of the OAuth 2.0 authorization code grant. As such, a server supporting these fields
上面描述的“grant_types”和“response_types”值是部分正交的，因为它们引用了在OAuth协议中传递给不同端点的参数。然而，它们是相关的，因为客户可用的“授权类型”影响客户允许使用的“响应类型”，反之亦然。例如，包含“授权代码”的“授权类型”值意味着包含“代码”的“响应类型”值，因为这两个值都定义为OAuth 2.0授权代码授权的一部分。因此，支持这些字段的服务器
SHOULD take steps to ensure that a client cannot register itself into an inconsistent state, for example, by returning an "invalid_client_metadata" error response to an inconsistent registration request.
应采取措施确保客户端无法将自己注册到不一致的状态，例如，通过对不一致的注册请求返回“invalid_client_metadata”错误响应。
The correlation between the two fields is listed in the table below.
下表列出了这两个字段之间的相关性。
+-----------------------------------------------+-------------------+
| grant_types value includes: | response_types |
| | value includes: |
+-----------------------------------------------+-------------------+
| authorization_code | code |
| implicit | token |
| password | (none) |
| client_credentials | (none) |
| refresh_token | (none) |
| urn:ietf:params:oauth:grant-type:jwt-bearer | (none) |
| urn:ietf:params:oauth:grant-type:saml2-bearer | (none) |
+-----------------------------------------------+-------------------+
+-----------------------------------------------+-------------------+
| grant_types value includes: | response_types |
| | value includes: |
+-----------------------------------------------+-------------------+
| authorization_code | code |
| implicit | token |
| password | (none) |
| client_credentials | (none) |
| refresh_token | (none) |
| urn:ietf:params:oauth:grant-type:jwt-bearer | (none) |
| urn:ietf:params:oauth:grant-type:saml2-bearer | (none) |
+-----------------------------------------------+-------------------+
Extensions and profiles of this document that introduce new values to either the "grant_types" or "response_types" parameter MUST document all correspondences between these two parameter types.
本文档的扩展和概要文件为“grant_types”或“response_types”参数引入新值时，必须记录这两种参数类型之间的所有对应关系。
Human-readable client metadata values and client metadata values that reference human-readable values MAY be represented in multiple languages and scripts. For example, the values of fields such as "client_name", "tos_uri", "policy_uri", "logo_uri", and "client_uri" might have multiple locale-specific values in some client registrations to facilitate use in different locations.
人类可读的客户端元数据值和引用人类可读值的客户端元数据值可以用多种语言和脚本表示。例如，诸如“客户机名称”、“tos_uri”、“策略_uri”、“徽标_uri”和“客户机_uri”等字段的值在一些客户机注册中可能具有多个特定于语言环境的值，以便于在不同位置使用。
To specify the languages and scripts, BCP 47 [RFC5646] language tags are added to client metadata member names, delimited by a "#" character. Since JSON [RFC7159] member names are case sensitive, it is RECOMMENDED that language tag values used in Claim Names be spelled using the character case with which they are registered in the "IANA Language Subtag" registry [IANA.Language]. In particular, normally language names are spelled with lowercase characters, region names are spelled with uppercase characters, and languages are spelled with mixed-case characters. However, since BCP 47 language tag values are case-insensitive, implementations SHOULD interpret the language tag values supplied in a case insensitive manner. Per the recommendations in BCP 47, language tag values used in metadata member names should only be as specific as necessary. For instance, using "fr" might be sufficient in many contexts, rather than "fr-CA" or "fr-FR".
要指定语言和脚本，将BCP 47[RFC5646]语言标记添加到客户端元数据成员名称中，并用“#”字符分隔。由于JSON[RFC7159]成员名称区分大小写，建议使用在“IANA语言子标记”注册表[IANA.language]中注册的字符大小写来拼写声明名称中使用的语言标记值。特别是，通常语言名称使用小写字符拼写，区域名称使用大写字符拼写，语言使用混合大小写字符拼写。但是，由于BCP 47语言标记值不区分大小写，因此实现应该以不区分大小写的方式解释提供的语言标记值。根据BCP 47中的建议，元数据成员名称中使用的语言标记值应仅在必要时具体。例如，在许多上下文中使用“fr”可能就足够了，而不是“fr-CA”或“fr-fr”。
For example, a client could represent its name in English as
"client_name#en": "My Client" and its name in Japanese as
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" within the same
registration request. The authorization server MAY display any or
all of these names to the resource owner during the authorization
step, choosing which name to display based on system configuration,
user preferences or other factors.
For example, a client could represent its name in English as
"client_name#en": "My Client" and its name in Japanese as
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" within the same
registration request. The authorization server MAY display any or
all of these names to the resource owner during the authorization
step, choosing which name to display based on system configuration,
user preferences or other factors.
If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as is wherever it is presented in a user interface. To facilitate interoperability, it is RECOMMENDED that clients and servers use a human-readable field without any language tags in addition to any language-specific fields, and it is RECOMMENDED that any human-readable fields sent without language tags contain values suitable for display on a wide variety of systems.
如果发送的任何人类可读字段没有语言标记，则使用该字段的各方不得对字符串值的语言、字符集或脚本做出任何假设，并且字符串值必须在用户界面中显示的任何位置按原样使用。为了促进互操作性，建议客户机和服务器除了使用任何语言特定字段外，还使用不带任何语言标记的人类可读字段，并且建议不带语言标记发送的任何人类可读字段包含适合在各种系统上显示的值。
Implementer's Note: Many JSON libraries make it possible to reference members of a JSON object as members of an object construct in the native programming environment of the library. However, while the "#" character is a valid character inside of a JSON object's member names, it is not a valid character for use in an object member name in many programming environments. Therefore, implementations will need to use alternative access forms for these claims. For instance, in JavaScript, if one parses the JSON as follows, "var j = JSON.parse(json);", then as a workaround the member "client_name#en-us" can be accessed using the JavaScript syntax "j["client_name#en-us"]".
实现者注意：许多JSON库使得在库的本机编程环境中将JSON对象的成员引用为对象构造的成员成为可能。但是，尽管“#”字符是JSON对象成员名称中的有效字符，但在许多编程环境中，它不是在对象成员名称中使用的有效字符。因此，对于这些声明，实现将需要使用替代的访问表单。例如，在JavaScript中，如果按照如下方式解析JSON，“var j=JSON.parse（JSON）；”，那么作为一种解决方法，可以使用JavaScript语法“j[“client_name#en us”]”访问成员“client_name#en us”。
A software statement is a JSON Web Token (JWT) [RFC7519] that asserts metadata values about the client software as a bundle. A set of claims that can be used in a software statement are defined in Section 2. When presented to the authorization server as part of a client registration request, the software statement MUST be digitally signed or MACed using JSON Web Signature (JWS) [RFC7515] and MUST contain an "iss" (issuer) claim denoting the party attesting to the claims in the software statement. It is RECOMMENDED that software statements be digitally signed using the "RS256" signature algorithm, although particular applications MAY specify the use of different algorithms. It is RECOMMENDED that software statements contain the "software_id" claim to allow authorization servers to correlate different instances of software using the same software statement.
软件语句是JSON Web令牌（JWT）[RFC7519]，它将有关客户端软件的元数据值作为一个包进行断言。第2节定义了可在软件语句中使用的一组声明。当作为客户机注册请求的一部分提交给授权服务器时，必须使用JSON Web签名（JWS）[RFC7515]对软件声明进行数字签名或标记，并且必须包含一个“iss”（发卡机构）声明，表示证明软件声明中声明的一方。建议使用“RS256”签名算法对软件语句进行数字签名，尽管特定应用程序可能指定使用不同的算法。建议软件语句包含“软件id”声明，以允许授权服务器使用同一软件语句关联不同的软件实例。
For example, a software statement could contain the following claims:
例如，软件语句可能包含以下声明：
{
"software_id": "4NRB1-0XZABZI9E6-5SM3R",
"client_name": "Example Statement-based Client",
"client_uri": "https://client.example.net/"
}
{
"software_id": "4NRB1-0XZABZI9E6-5SM3R",
"client_name": "Example Statement-based Client",
"client_uri": "https://client.example.net/"
}
The following non-normative example JWT includes these claims and has been asymmetrically signed using "RS256" (with line breaks for display purposes only):
以下非规范性示例JWT包括这些权利要求，并已使用“RS256”进行不对称签名（换行符仅用于显示目的）：
eyJhbGciOiJSUzI1NiJ9. eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ. GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0 5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA
eyJhbGciOiJSUzI1NiJ9。EYJZB2 Z0D2FYZV9PZCI6IJRUUKIXLTBYWKFCWKK5RTYTNVRM1IILCJJBGLL BNRFBMFTZSI6IKV4YW1WBGU3RHDGVTZW50LWJHC2VKIENSAWVUDCISIMN AWVUDF91CMKIOIJODHRWCZOVL2NAWVUDC5LEGFTCL5LDC8IFQ。8月8日，一家报纸在一家报纸上发表了一篇文章。一家报纸在一家报纸上发表了一篇文章，在一家报纸上发表了一篇文章，在一家报纸上发表了一篇文章，在一家报纸上发表了一篇文章。一家报纸在一家报纸上发表了一篇文章，在一家报纸上发表了一篇文章。一家报纸上的一家报纸在一家报纸上发表了一篇文章。一家报纸上，一家报纸上的一家报纸在一家报纸上的一家报纸上，一家报纸上的一家报纸在一家报纸上的一家报纸上，一家报纸上，一家报纸上的一家报纸上一家报纸上的一家报纸上一家报纸上的一家报纸上，一家报纸上，一家报纸上一家报纸上的一家报纸上的一家报纸上一家报纸上一家报纸上一家报纸一家报纸上的一家报纸上的一家报纸上一家报纸上一家报纸ZTJ0Y2OE0_EJAiXbL6OyF9S5tKxDXV8JIndSA
The software statement is typically distributed with all instances of a client application. The means by which a client or developer obtains a software statement are outside the scope of this specification. Some common methods could include a client developer generating a client-specific JWT by registering with a software API publisher to obtain a software statement for a class of clients.
软件语句通常与客户端应用程序的所有实例一起分发。客户或开发人员获取软件声明的方式不在本规范的范围内。一些常见的方法可能包括客户端开发人员通过向软件API发布者注册来生成特定于客户端的JWT，以获取一类客户端的软件语句。
The criteria by which authorization servers determine whether to trust and utilize the information in a software statement are outside the scope of this specification.
授权服务器确定是否信任和利用软件语句中的信息的标准不在本规范的范围内。
In some cases, authorization servers MAY choose to accept a software statement value directly as a client identifier in an authorization request, without a prior dynamic client registration having been performed. The circumstances under which an authorization server would do so, and the specific software statement characteristics required in this case, are outside the scope of this specification.
在某些情况下，授权服务器可以选择直接接受软件语句值作为授权请求中的客户端标识符，而无需事先执行动态客户端注册。授权服务器执行此操作的情况以及本例中所需的特定软件语句特征不在本规范的范围内。
The client registration endpoint is an OAuth 2.0 endpoint defined in this document that is designed to allow a client to be registered with the authorization server. The client registration endpoint MUST accept HTTP POST messages with request parameters encoded in the
客户端注册端点是本文档中定义的OAuth 2.0端点，旨在允许向授权服务器注册客户端。客户端注册终结点必须接受HTTP POST消息，其请求参数编码在
entity body using the "application/json" format. The client registration endpoint MUST be protected by a transport-layer security mechanism, as described in Section 5.
实体主体使用“application/json”格式。客户端注册端点必须由传输层安全机制保护，如第5节所述。
The client registration endpoint MAY be an OAuth 2.0 [RFC6749] protected resource and it MAY accept an initial access token in the form of an OAuth 2.0 access token to limit registration to only previously authorized parties. The method by which the initial access token is obtained by the client or developer is generally out of band and is out of scope for this specification. The method by which the initial access token is verified and validated by the client registration endpoint is out of scope for this specification.
客户端注册端点可以是受OAuth 2.0[RFC6749]保护的资源，并且它可以接受OAuth 2.0访问令牌形式的初始访问令牌，以将注册限制为仅先前授权的方。客户端或开发人员获取初始访问令牌的方法通常是带外的，不在本规范的范围内。客户端注册端点验证初始访问令牌的方法超出了本规范的范围。
To support open registration and facilitate wider interoperability, the client registration endpoint SHOULD allow registration requests with no authorization (which is to say, with no initial access token in the request). These requests MAY be rate-limited or otherwise limited to prevent a denial-of-service attack on the client registration endpoint.
为了支持开放注册并促进更广泛的互操作性，客户端注册端点应该允许无授权的注册请求（也就是说，请求中没有初始访问令牌）。这些请求可能受到速率限制或其他限制，以防止对客户端注册端点的拒绝服务攻击。
This operation registers a client with the authorization server. The authorization server assigns this client a unique client identifier, optionally assigns a client secret, and associates the metadata provided in the request with the issued client identifier. The request includes any client metadata parameters being specified for the client during the registration. The authorization server MAY provision default values for any items omitted in the client metadata.
此操作向授权服务器注册客户端。授权服务器为该客户机分配唯一的客户机标识符，可选地分配客户机机密，并将请求中提供的元数据与发布的客户机标识符相关联。该请求包括注册期间为客户端指定的任何客户端元数据参数。授权服务器可以为客户端元数据中省略的任何项提供默认值。
To register, the client or developer sends an HTTP POST to the client registration endpoint with a content type of "application/json". The HTTP Entity Payload is a JSON [RFC7159] document consisting of a JSON object and all requested client metadata values as top-level members of that JSON object.
为了注册，客户机或开发人员向客户机注册端点发送内容类型为“application/json”的HTTP POST。HTTP实体有效负载是一个JSON[RFC7159]文档，由一个JSON对象和作为该JSON对象顶级成员的所有请求的客户端元数据值组成。
For example, if the server supports open registration (with no initial access token), the client could send the following registration request to the client registration endpoint.
例如，如果服务器支持开放注册（没有初始访问令牌），则客户端可以向客户端注册端点发送以下注册请求。
The following is a non-normative example request not using an initial access token:
以下是不使用初始访问令牌的非规范性示例请求：
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
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"
}
{
"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"
}
Alternatively, if the server supports authorized registration, the developer or the client will be provisioned with an initial access token. (The method by which the initial access token is obtained is out of scope for this specification.) The developer or client sends the following authorized registration request to the client registration endpoint. Note that the initial access token sent in this example as an OAuth 2.0 Bearer Token [RFC6750], but any OAuth 2.0 token type could be used by an authorization server.
或者，如果服务器支持授权注册，则将为开发人员或客户端提供初始访问令牌。（获取初始访问令牌的方法超出了本规范的范围。）开发人员或客户端向客户端注册端点发送以下授权注册请求。注意，在本例中作为OAuth 2.0承载令牌[RFC6750]发送的初始访问令牌，但授权服务器可以使用任何OAuth 2.0令牌类型。
The following is a non-normative example request using an initial access token and registering a JWK Set by value (with line breaks within values for display purposes only):
以下是一个非规范性示例请求，使用初始访问令牌并注册由值设置的JWK（值中的换行符仅用于显示目的）：
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Authorization: Bearer ey23f2.adfj230.af32-developer321
Host: server.example.com
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"
}
{
"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"
}
In addition to JSON elements, client metadata values MAY also be provided in a software statement, as described in Section 2.3. The authorization server MAY ignore the software statement if it does not support this feature. If the server supports software statements, client metadata values conveyed in the software statement MUST take precedence over those conveyed using plain JSON elements.
除JSON元素外，还可以在软件语句中提供客户端元数据值，如第2.3节所述。如果授权服务器不支持此功能，它可能会忽略软件语句。如果服务器支持软件语句，则软件语句中传递的客户端元数据值必须优先于使用普通JSON元素传递的值。
Software statements are included in the requesting JSON object using this OPTIONAL member:
软件语句包含在使用此可选成员的请求JSON对象中：
software_statement A software statement containing client metadata values about the client software as claims. This is a string value containing the entire signed JWT.
软件声明一种软件声明，包含有关客户端软件的客户端元数据值，如声明所述。这是一个包含整个带符号JWT的字符串值。
In the following example, some registration parameters are conveyed as claims in a software statement from the example in Section 2.3, while some values specific to the client instance are conveyed as regular parameters (with line breaks within values for display purposes only):
在以下示例中，一些注册参数作为声明在第2.3节示例中的软件语句中传递，而特定于客户端实例的一些值作为常规参数传递（值中的换行符仅用于显示目的）：
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
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"
}
{
"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"
}
Upon a successful registration request, the authorization server returns a client identifier for the client. The server responds with an HTTP 201 Created status code and a body of type "application/json" with content as described in Section 3.2.1.
注册请求成功后，授权服务器返回客户端的客户端标识符。服务器使用HTTP 201创建的状态代码和类型为“application/json”的主体进行响应，内容如第3.2.1节所述。
Upon an unsuccessful registration request, the authorization server responds with an error, as described in Section 3.2.2.
注册请求不成功时，授权服务器响应错误，如第3.2.2节所述。
The response contains the client identifier as well as the client secret, if the client is a confidential client. The response MAY contain additional fields as specified by extensions to this specification.
如果客户机是机密客户机，则响应包含客户机标识符以及客户机机密。响应可能包含本规范扩展指定的其他字段。
client_id REQUIRED. OAuth 2.0 client identifier string. It SHOULD NOT be currently valid for any other registered client, though an authorization server MAY issue the same client identifier to multiple instances of a registered client at its discretion.
需要客户端id。OAuth 2.0客户端标识符字符串。尽管授权服务器可自行决定向注册客户端的多个实例颁发相同的客户端标识符，但该标识符当前不应对任何其他注册客户端有效。
client_secret OPTIONAL. OAuth 2.0 client secret string. If issued, this MUST be unique for each "client_id" and SHOULD be unique for multiple instances of a client using the same "client_id". This value is used by confidential clients to authenticate to the token endpoint, as described in OAuth 2.0 [RFC6749], Section 2.3.1.
客户机密码可选。OAuth 2.0客户端机密字符串。如果发出，则每个“客户机id”都必须是唯一的，并且对于使用相同“客户机id”的多个客户机实例来说应该是唯一的。机密客户端使用此值对令牌端点进行身份验证，如OAuth 2.0[RFC6749]第2.3.1节所述。
client_id_issued_at OPTIONAL. Time at which the client identifier was issued. The time is represented as the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time of issuance.
客户id在可选位置发布。发出客户端标识符的时间。时间表示为从1970-01-01T00:00:00Z（以UTC为单位）到发布日期/时间的秒数。
client_secret_expires_at REQUIRED if "client_secret" is issued. Time at which the client secret will expire or 0 if it will not expire. The time is represented as the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time of expiration.
如果发布了“客户机密”，则客户机密将在需要时过期。客户端密码将过期的时间，如果不过期，则为0。时间表示为从1970-01-01T00:00:00Z（以UTC为单位）到到期日期/时间的秒数。
Additionally, the authorization server MUST return all registered metadata about this client, including any fields provisioned by the authorization server itself. The authorization server MAY reject or replace any of the client's requested metadata values submitted during the registration and substitute them with suitable values. The client or developer can check the values in the response to determine if the registration is sufficient for use (e.g., the registered "token_endpoint_auth_method" is supported by the client software) and determine a course of action appropriate for the client software. The response to such a situation is out of scope for this specification but could include filing a report with the application developer or authorization server provider, attempted re-registration with different metadata values, or various other methods. For instance, if the server also supports a registration management mechanism such as that defined in [RFC7592], the client or developer could attempt to update the registration with different metadata values. This process could also be aided by a service discovery protocol, such as [OpenID.Discovery], which can list a server's capabilities, allowing a client to make a more informed registration request. The use of any such management or discovery system is optional and outside the scope of this specification.
此外，授权服务器必须返回有关此客户端的所有已注册元数据，包括授权服务器本身设置的任何字段。授权服务器可以拒绝或替换注册期间提交的任何客户端请求的元数据值，并用合适的值替换它们。客户端或开发人员可以检查响应中的值，以确定注册是否足以使用（例如，客户端软件支持注册的“令牌\端点\验证\方法”），并确定适合客户端软件的操作过程。对这种情况的响应超出了本规范的范围，但可能包括向应用程序开发人员或授权服务器提供商提交报告、尝试使用不同的元数据值重新注册或各种其他方法。例如，如果服务器还支持[RFC7592]中定义的注册管理机制，则客户端或开发人员可以尝试使用不同的元数据值更新注册。这一过程还可以通过服务发现协议（如[OpenID.discovery]）来辅助，该协议可以列出服务器的功能，从而允许客户机发出更明智的注册请求。任何此类管理或发现系统的使用都是可选的，不在本规范的范围内。
The successful registration response uses an HTTP 201 Created status code with a body of type "application/json" consisting of a single JSON object [RFC7159] with all parameters as top-level members of the object.
成功的注册响应使用HTTP 201创建的状态代码，其主体类型为“application/json”，由单个json对象[RFC7159]组成，所有参数都作为该对象的顶级成员。
If a software statement was used as part of the registration, its value MUST be returned unmodified in the response along with other metadata using the "software_statement" member name. Client metadata elements used from the software statement MUST also be returned directly as top-level client metadata values in the registration response (possibly with different values, since the values requested and the values used may differ).
如果将软件语句用作注册的一部分，则其值必须在响应中未经修改地返回，并与使用“software_statement”成员名称的其他元数据一起返回。从软件语句中使用的客户端元数据元素也必须作为注册响应中的顶级客户端元数据值直接返回（可能具有不同的值，因为请求的值和使用的值可能不同）。
The following is a non-normative example response of a successful registration:
以下是成功注册的非规范性示例响应：
HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
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"
}
{
"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"
}
When an OAuth 2.0 error condition occurs, such as the client presenting an invalid initial access token, the authorization server returns an error response appropriate to the OAuth 2.0 token type.
当发生OAuth 2.0错误情况时，例如客户端呈现无效的初始访问令牌，授权服务器将返回适用于OAuth 2.0令牌类型的错误响应。
When a registration error condition occurs, the authorization server returns an HTTP 400 status code (unless otherwise specified) with content type "application/json" consisting of a JSON object [RFC7159] describing the error in the response body.
当出现注册错误情况时，授权服务器返回一个HTTP 400状态代码（除非另有规定），其内容类型为“application/json”，由一个json对象[RFC7159]组成，描述响应正文中的错误。
Two members are defined for inclusion in the JSON object:
定义了两个成员以包含在JSON对象中：
error REQUIRED. Single ASCII error code string.
错误要求。单个ASCII错误代码字符串。
error_description OPTIONAL. Human-readable ASCII text description of the error used for debugging.
错误描述是可选的。用于调试的错误的人类可读ASCII文本描述。
Other members MAY also be included and, if they are not understood, they MUST be ignored.
其他成员也可能包括在内，如果不理解，则必须忽略。
This specification defines the following error codes:
本规范定义了以下错误代码：
invalid_redirect_uri The value of one or more redirection URIs is invalid.
无效的\u重定向\u uri一个或多个重定向uri的值无效。
invalid_client_metadata The value of one of the client metadata fields is invalid and the server has rejected this request. Note that an authorization server MAY choose to substitute a valid value for any requested parameter of a client's metadata.
无效的\u客户端\u元数据其中一个客户端元数据字段的值无效，服务器已拒绝此请求。请注意，授权服务器可以选择用有效值替换客户端元数据的任何请求参数。
invalid_software_statement The software statement presented is invalid.
无效的\u软件\u语句显示的软件语句无效。
unapproved_software_statement The software statement presented is not approved for use by this authorization server.
未批准的\u软件\u语句提交的软件语句未批准此授权服务器使用。
The following is a non-normative example of an error response resulting from a redirection URI that has been blacklisted by the authorization server (with line breaks within values for display purposes only):
以下是由已被授权服务器列入黑名单的重定向URI（值中的换行符仅用于显示目的）导致的错误响应的非规范性示例：
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
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."
}
{
"error": "invalid_redirect_uri",
"error_description": "The redirection URI
http://sketchy.example.com is not allowed by this server."
}
The following is a non-normative example of an error response resulting from an inconsistent combination of "response_types" and "grant_types" values (with line breaks within values for display purposes only):
以下是由“响应类型”和“授予类型”值的不一致组合导致的错误响应的非规范性示例（值中的换行符仅用于显示目的）：
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
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."
}
{
"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."
}
This specification establishes the "OAuth Dynamic Client Registration Metadata" registry.
本规范建立了“OAuth动态客户端注册元数据”注册表。
OAuth registration client metadata names and descriptions are registered with a Specification Required ([RFC5226]) after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of names prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published, per [RFC7120].
OAuth注册客户端元数据名称和描述在OAuth ext上经过两周的审查后，按照所需规范（[RFC5226]）注册-review@ietf.org根据一名或多名指定专家的建议，提供邮件列表。但是，为了允许在发布前分配名称，指定专家可在其确信将根据[RFC7120]发布此类规范后批准注册。
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Dynamic Client Registration Metadata name: example").
发送到邮件列表供审查的注册请求应使用适当的主题（例如，“注册OAuth动态客户端注册元数据名称的请求：示例”）。
Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
在审查期内，指定专家将批准或拒绝注册请求，并将此决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。
IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.
IANA必须只接受指定专家的注册更新，并将所有注册请求发送至审查邮件列表。
Client Metadata Name: The name requested (e.g., "example"). This name is case sensitive. Names that match other registered names in a case-insensitive manner SHOULD NOT be accepted.
客户端元数据名称：请求的名称（例如，“示例”）。此名称区分大小写。不应接受以不区分大小写的方式与其他注册名称匹配的名称。
Client Metadata Description: Brief description of the metadata value (e.g., "Example description").
客户端元数据描述：元数据值的简要描述（例如，“示例描述”）。
Change Controller: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请列出“IESG”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
Specification Document(s): Reference to the document or documents that specify the client metadata definition, preferably including a URI that can be used to retrieve a copy of the documents. An indication of the relevant sections may also be included but is not required.
规范文档：对指定客户端元数据定义的一个或多个文档的引用，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
The initial contents of the "OAuth Dynamic Client Registration Metadata" registry are:
“OAuth动态客户端注册元数据”注册表的初始内容是：
o Client Metadata Name: "redirect_uris" o Client Metadata Description: Array of redirection URIs for use in redirect-based flows o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“重定向URI”o客户端元数据描述：用于基于重定向的流的重定向URI数组o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "token_endpoint_auth_method" o Client Metadata Description: Requested authentication method for the token endpoint o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“令牌\端点\身份验证\方法”o客户端元数据描述：请求的令牌端点身份验证方法o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "grant_types" o Client Metadata Description: Array of OAuth 2.0 grant types that the client may use o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“授权类型”o客户端元数据描述：客户端可以使用的OAuth 2.0授权类型数组o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "response_types" o Client Metadata Description: Array of the OAuth 2.0 response types that the client may use o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“响应类型”o客户端元数据描述：客户端可以使用的OAuth 2.0响应类型数组o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "client_name" o Client Metadata Description: Human-readable name of the client to be presented to the user o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户机元数据名称：“客户机名称”o客户机元数据描述：要呈现给用户的客户机可读名称o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "client_uri" o Client Metadata Description: URL of a web page providing information about the client o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“Client_uri”o客户端元数据描述：提供有关客户端的信息的网页的URL o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "logo_uri" o Client Metadata Description: URL that references a logo for the client o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“logo_uri”o客户端元数据描述：引用客户端徽标的URL o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "scope" o Client Metadata Description: Space-separated list of OAuth 2.0 scope values o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“范围”o客户端元数据描述：OAuth 2.0范围值的空格分隔列表o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "contacts" o Client Metadata Description: Array of strings representing ways to contact people responsible for this client, typically email addresses o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“联系人”o客户端元数据描述：字符串数组，表示联系负责此客户端的人员的方式，通常为电子邮件地址o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "tos_uri" o Client Metadata Description: URL that points to a human-readable terms of service document for the client o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户机元数据名称：“tos_uri”o客户机元数据描述：指向客户机可读服务条款文档的URL o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "policy_uri" o Client Metadata Description: URL that points to a human-readable policy document for the client o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“policy_uri”o客户端元数据描述：指向客户端的可读策略文档的URL o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "jwks_uri" o Client Metadata Description: URL referencing the client's JSON Web Key Set [RFC7517] document representing the client's public keys o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“jwks_uri”o客户端元数据描述：URL引用客户端的JSON Web密钥集[RFC7517]文档，表示客户端的公钥o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "jwks" o Client Metadata Description: Client's JSON Web Key Set [RFC7517] document representing the client's public keys o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“jwks”o客户端元数据描述：表示客户端公钥的客户端JSON Web密钥集[RFC7517]文档o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "software_id" o Client Metadata Description: Identifier for the software that comprises a client o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“软件\u id”o客户端元数据描述：包含客户端的软件标识符o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "software_version" o Client Metadata Description: Version identifier for the software that comprises a client o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“软件版本”o客户端元数据描述：包含客户端的软件的版本标识符o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "client_id" o Client Metadata Description: Client identifier o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“客户端id”o客户端元数据描述：客户端标识符o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "client_secret" o Client Metadata Description: Client secret o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“客户端\u机密”o客户端元数据描述：客户端机密o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "client_id_issued_at" o Client Metadata Description: Time at which the client identifier was issued o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户机元数据名称：“客户机id发布时间”o客户机元数据描述：发布客户机标识符的时间o更改控制器：IESG o规范文档：RFC 7591
o Client Metadata Name: "client_secret_expires_at" o Client Metadata Description: Time at which the client secret will expire o Change Controller: IESG o Specification Document(s): RFC 7591
o 客户端元数据名称：“客户端\u密码\u过期时间”o客户端元数据描述：客户端密码过期的时间o更改控制器：IESG o规范文档：RFC 7591
This specification establishes the "OAuth Token Endpoint Authentication Methods" registry.
本规范建立了“OAuth令牌端点身份验证方法”注册表。
Additional values for use as "token_endpoint_auth_method" values are registered with a Specification Required ([RFC5226]) after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published, per [RFC7120].
在oauth ext上经过两周的审查后，使用所需规范（[RFC5226]）注册用作“令牌\端点\验证\方法”值的附加值-review@ietf.org根据一名或多名指定专家的建议，提供邮件列表。但是，为了允许在发布之前分配值，指定专家可在他们确信将根据[RFC7120]发布此类规范后批准注册。
Registration requests must be sent to the oauth-ext-review@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request to register token_endpoint_auth_method value: example").
注册请求必须发送到oauth ext-review@ietf.org用于审查和评论的邮件列表，带有适当的主题（例如，“请求注册令牌\端点\验证\方法值：示例”）。
Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
在审查期内，指定专家将批准或拒绝注册请求，并将此决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。
IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.
IANA必须只接受指定专家的注册更新，并将所有注册请求发送至审查邮件列表。
Token Endpoint Authentication Method Name: The name requested (e.g., "example"). This name is case sensitive. Names that match other registered names in a case-insensitive manner SHOULD NOT be accepted.
令牌端点身份验证方法名称：请求的名称（例如，“示例”）。此名称区分大小写。不应接受以不区分大小写的方式与其他注册名称匹配的名称。
Change Controller: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请列出“IESG”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
Specification Document(s): Reference to the document or documents that specify the token endpoint authentication method, preferably including a URI that can be used to retrieve a copy of the document or documents. An indication of the relevant sections may also be included but is not required.
规范文档：对指定令牌端点身份验证方法的一个或多个文档的引用，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
The initial contents of the "OAuth Token Endpoint Authentication Methods" registry are:
“OAuth令牌端点身份验证方法”注册表的初始内容为：
o Token Endpoint Authentication Method Name: "none" o Change Controller: IESG o Specification Document(s): RFC 7591
o 令牌端点身份验证方法名称：“无”o更改控制器：IESG o规范文档：RFC 7591
o Token Endpoint Authentication Method Name: "client_secret_post" o Change Controller: IESG o Specification Document(s): RFC 7591
o 令牌端点身份验证方法名称：“客户端加密”o更改控制器：IESG o规范文档：RFC 7591
o Token Endpoint Authentication Method Name: "client_secret_basic" o Change Controller: IESG o Specification Document(s): RFC 7591
o 令牌端点身份验证方法名称：“客户端\u机密\u基本”o更改控制器：IESG o规范文档：RFC 7591
Since requests to the client registration endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the authorization server MUST require the use of a transport-layer security mechanism when sending requests to the registration endpoint. The server MUST support TLS 1.2 [RFC5246] and MAY support additional transport-layer security mechanisms meeting its security requirements. When using TLS, the client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. Implementation security considerations can be found in Recommendations for Secure Use of TLS and DTLS [BCP195].
由于对客户端注册端点的请求会导致明文凭证的传输（在HTTP请求和响应中），因此授权服务器在向注册端点发送请求时必须使用传输层安全机制。服务器必须支持TLS 1.2[RFC5246]，并且可以支持满足其安全要求的其他传输层安全机制。使用TLS时，客户机必须按照RFC 6125[RFC6125]执行TLS/SSL服务器证书检查。实施安全注意事项可在TLS和DTL安全使用建议[BCP195]中找到。
For clients that use redirect-based grant types such as "authorization_code" and "implicit", authorization servers MUST require clients to register their redirection URI values. This can help mitigate attacks where rogue actors inject and impersonate a validly registered client and intercept its authorization code or tokens through an invalid redirection URI or open redirector. Additionally, in order to prevent hijacking of the return values of the redirection, registered redirection URI values MUST be one of:
对于使用基于重定向的授权类型（如“授权\代码”和“隐式”）的客户端，授权服务器必须要求客户端注册其重定向URI值。这有助于减轻恶意参与者通过无效重定向URI或开放重定向器注入和模拟有效注册的客户端并截获其授权代码或令牌的攻击。此外，为了防止劫持重定向的返回值，注册的重定向URI值必须是以下值之一：
o A remote web site protected by TLS (e.g., https://client.example.com/oauth_redirect) o A web site hosted on the local machine using an HTTP URI (e.g., http://localhost:8080/oauth_redirect) o A non-HTTP application-specific URL that is available only to the client application (e.g., exampleapp://oauth_redirect)
o 受TLS保护的远程网站（例如。，https://client.example.com/oauth_redirect)o使用HTTP URI托管在本地计算机上的网站（例如。，http://localhost:8080/oauth_redirect)o仅对客户端应用程序可用的非HTTP应用程序特定URL（例如xampleapp://oauth_redirect)
Public clients MAY register with an authorization server using this protocol, if the authorization server's policy allows them. Public clients use a "none" value for the "token_endpoint_auth_method" metadata field and are generally used with the "implicit" grant type. Often these clients will be short-lived in-browser applications requesting access to a user's resources and access is tied to a user's active session at the authorization server. Since such clients often do not have long-term storage, it is possible that such clients would need to re-register every time the browser application is loaded. To avoid the resulting proliferation of dead client identifiers, an authorization server MAY decide to expire registrations for existing clients meeting certain criteria after a period of time has elapsed. Alternatively, such clients could be registered on the server where the in-browser application's code is served from, and the client's configuration could be pushed to the browser alongside the code.
如果授权服务器的策略允许，公共客户端可以使用此协议向授权服务器注册。公共客户端对“令牌\端点\身份验证\方法”元数据字段使用“无”值，通常与“隐式”授权类型一起使用。在请求访问用户资源的浏览器应用程序中，这些客户端通常是短期的，并且访问权限与用户在授权服务器上的活动会话有关。由于此类客户端通常没有长期存储，因此每次加载浏览器应用程序时，此类客户端可能需要重新注册。为了避免导致死机客户端标识符的激增，授权服务器可能会在一段时间后决定使满足某些条件的现有客户端的注册过期。或者，这样的客户机可以在服务器上注册，浏览器内应用程序的代码从服务器提供，客户机的配置可以与代码一起推送到浏览器。
Since different OAuth 2.0 grant types have different security and usage properties, an authorization server MAY require separate registrations for a piece of software to support multiple grant types. For instance, an authorization server might require that all clients using the "authorization_code" grant type make use of a client secret for the "token_endpoint_auth_method" but any clients using the "implicit" grant type not use any authentication at the token endpoint. In such a situation, a server MAY disallow clients from registering for both the "authorization_code" and "implicit" grant types simultaneously. Similarly, the "authorization_code" grant type is used to represent access on behalf of an end-user, but the "client_credentials" grant type represents access on behalf of the client itself. For security reasons, an authorization server could require that different scopes be used for these different use
由于不同的OAuth 2.0授权类型具有不同的安全性和使用属性，因此授权服务器可能需要对软件进行单独注册，以支持多种授权类型。例如，授权服务器可能要求所有使用“authorization_code”授权类型的客户端使用“token_endpoint_auth_method”的客户端机密，但任何使用“implicit”授权类型的客户端都不在令牌端点使用任何身份验证。在这种情况下，服务器可能会禁止客户端同时注册“授权\代码”和“隐式”授权类型。类似地，“authorization\u code”授权类型用于代表最终用户的访问，但“client\u credentials”授权类型代表代表客户端本身的访问。出于安全原因，授权服务器可能要求为这些不同的用途使用不同的作用域
cases, and, as a consequence, it MAY disallow these two grant types from being registered together by the same client. In all of these cases, the authorization server would respond with an "invalid_client_metadata" error response.
因此，它可能不允许同一客户同时注册这两种授权类型。在所有这些情况下，授权服务器将以“无效的客户端元数据”错误响应进行响应。
Unless used as a claim in a software statement, the authorization server MUST treat all client metadata as self-asserted. For instance, a rogue client might use the name and logo of a legitimate client that it is trying to impersonate. Additionally, a rogue client might try to use the software identifier or software version of a legitimate client to attempt to associate itself on the authorization server with instances of the legitimate client. To counteract this, an authorization server MUST take appropriate steps to mitigate this risk by looking at the entire registration request and client configuration. For instance, an authorization server could issue a warning if the domain/site of the logo doesn't match the domain/site of redirection URIs. An authorization server could also refuse registration requests from a known software identifier that is requesting different redirection URIs or a different client URI. An authorization server can also present warning messages to end-users about dynamically registered clients in all cases, especially if such clients have been recently registered or have not been trusted by any users at the authorization server before.
除非在软件语句中用作声明，否则授权服务器必须将所有客户端元数据视为自断言。例如，流氓客户端可能会使用它试图模拟的合法客户端的名称和徽标。此外，恶意客户端可能会尝试使用合法客户端的软件标识符或软件版本，试图将授权服务器上的自身与合法客户端的实例相关联。为了解决这一问题，授权服务器必须采取适当的步骤，通过查看整个注册请求和客户端配置来降低此风险。例如，如果徽标的域/站点与重定向URI的域/站点不匹配，授权服务器可能会发出警告。授权服务器还可以拒绝来自正在请求不同重定向URI或不同客户端URI的已知软件标识符的注册请求。授权服务器还可以在所有情况下向最终用户显示有关动态注册的客户端的警告消息，特别是如果此类客户端最近已注册或以前未被授权服务器上的任何用户信任。
In a situation where the authorization server is supporting open client registration, it must be extremely careful with any URL provided by the client that will be displayed to the user (e.g., "logo_uri", "tos_uri", "client_uri", and "policy_uri"). For instance, a rogue client could specify a registration request with a reference to a drive-by download in the "policy_uri", enticing the user to click on it during the authorization. The authorization server SHOULD check to see if the "logo_uri", "tos_uri", "client_uri", and "policy_uri" have the same host and scheme as the those defined in the array of "redirect_uris" and that all of these URIs resolve to valid web pages. Since these URI values that are intended to be displayed to the user at the authorization page, the authorization server SHOULD protect the user from malicious content hosted at the URLs where possible. For instance, before presenting the URLs to the user at the authorization page, the authorization server could download the content hosted at the URLs, check the content against a malware scanner and blacklist filter, determine whether or not there is mixed secure and non-secure content at the URL, and other possible server-side mitigations. Note that the content in these URLs can change at any time and the authorization server cannot provide complete confidence in the safety of the URLs, but these practices could help. To further mitigate this kind of threat, the authorization server can also warn the user that the URL links have been provided by a third party, should be treated with
在授权服务器支持开放客户端注册的情况下，必须非常小心客户端提供的任何将显示给用户的URL（例如，“logo_uri”、“tos_uri”、“client_uri”和“policy_uri”）。例如，恶意客户端可以在“policy_uri”中指定一个注册请求，并引用一个drive by download，诱使用户在授权期间单击该请求。授权服务器应该检查“logo_uri”、“tos_uri”、“client_uri”和“policy_uri”是否与“redirect_uri”数组中定义的主机和方案相同，并且所有这些uri都解析为有效的网页。由于这些URI值旨在在授权页面上显示给用户，因此授权服务器应尽可能保护用户免受URL上托管的恶意内容的影响。例如，在授权页面向用户呈现URL之前，授权服务器可以下载URL上承载的内容，根据恶意软件扫描程序和黑名单过滤器检查内容，确定URL上是否存在安全和非安全混合内容，以及其他可能的服务器端缓解措施。请注意，这些URL中的内容可以随时更改，授权服务器无法完全信任URL的安全性，但这些做法可能会有所帮助。为了进一步减轻这种威胁，授权服务器还可以警告用户，URL链接是由第三方提供的，应该使用
caution, and are not hosted by the authorization server itself. For instance, instead of providing the links directly in an HTML anchor, the authorization server can direct the user to an interstitial warning page before allowing the user to continue to the target URL.
注意，并且不是由授权服务器本身托管的。例如，授权服务器可以在允许用户继续访问目标URL之前，将用户引导到间隙警告页面，而不是直接在HTML锚中提供链接。
Clients MAY use both the direct JSON object and the JWT-encoded software statement to present client metadata to the authorization server as part of the registration request. A software statement is cryptographically protected and represents claims made by the issuer of the statement, while the JSON object represents the self-asserted claims made by the client or developer directly. If the software statement is valid and signed by an acceptable authority (such as the software API publisher), the values of client metadata within the software statement MUST take precedence over those metadata values presented in the plain JSON object, which could have been intercepted and modified.
客户端可以使用直接JSON对象和JWT编码的软件语句将客户端元数据作为注册请求的一部分呈现给授权服务器。软件语句受密码保护，表示语句发布者的声明，而JSON对象表示客户端或开发人员直接作出的自我声明声明。如果软件语句有效并由可接受的权威机构（如软件API发布者）签名，则软件语句中的客户端元数据值必须优先于普通JSON对象中显示的元数据值，这些值可能已被截获和修改。
Like all metadata values, the software statement is an item that is self-asserted by the client, even though its contents have been digitally signed or MACed by the issuer of the software statement. As such, presentation of the software statement is not sufficient in most cases to fully identify a piece of client software. An initial access token, in contrast, does not necessarily contain information about a particular piece of client software but instead represents authorization to use the registration endpoint. An authorization server MUST consider the full registration request, including the software statement, initial access token, and JSON client metadata values, when deciding whether to honor a given registration request.
与所有元数据值一样，软件语句是一个由客户端自行声明的项，即使其内容已由软件语句的发布者进行了数字签名或标记。因此，在大多数情况下，软件语句的表示不足以完全识别客户机软件。相反，初始访问令牌不一定包含关于特定客户端软件的信息，而是表示使用注册端点的授权。授权服务器必须考虑完整的注册请求，包括软件语句、初始访问令牌和JSON客户端元数据值，当决定是否遵守给定的注册请求时。
If an authorization server receives a registration request for a client that is not intended to have multiple instances registered simultaneously and the authorization server can infer a duplication of registration (e.g., it uses the same "software_id" and "software_version" values as another existing client), the server SHOULD treat the new registration as being suspect and reject the registration. It is possible that the new client is trying to impersonate the existing client in order to trick users into authorizing it, or that the original registration is no longer valid. The details of managing this situation are specific to the authorization server deployment and outside the scope of this specification.
如果授权服务器接收到不打算同时注册多个实例的客户端的注册请求，并且授权服务器可以推断注册的重复（例如，它使用与另一个现有客户端相同的“软件id”和“软件版本”值），服务器应将新注册视为可疑，并拒绝注册。可能是新客户端试图模拟现有客户端以诱骗用户对其进行授权，或者原始注册不再有效。管理这种情况的详细信息特定于授权服务器部署，不在本规范的范围内。
Since a client identifier is a public value that can be used to impersonate a client at the authorization endpoint, an authorization server that decides to issue the same client identifier to multiple instances of a registered client needs to be very particular about the circumstances under which this occurs. For instance, the authorization server can limit a given client identifier to clients
由于客户机标识符是可用于在授权端点处模拟客户机的公共值，因此决定向已注册客户机的多个实例颁发相同客户机标识符的授权服务器需要非常详细地了解发生这种情况的情况。例如，授权服务器可以将给定的客户端标识符限制为客户端
using the same redirect-based flow and the same redirection URIs. An authorization server SHOULD NOT issue the same client secret to multiple instances of a registered client, even if they are issued the same client identifier, or else the client secret could be leaked, allowing malicious impostors to impersonate a confidential client.
使用相同的基于重定向的流和相同的重定向URI。授权服务器不应向已注册客户机的多个实例发布相同的客户机机密，即使它们被发布了相同的客户机标识符，否则客户机机密可能会泄漏，从而允许恶意冒名顶替者模拟机密客户机。
As the protocol described in this specification deals almost exclusively with information about software and not people, there are very few privacy concerns for its use. The notable exception is the "contacts" field as defined in Section 2, which contains contact information for the developers or other parties responsible for the client software. These values are intended to be displayed to end-users and will be available to the administrators of the authorization server. As such, the developer may wish to provide an email address or other contact information expressly dedicated to the purpose of supporting the client instead of using their personal or professional addresses. Alternatively, the developer may wish to provide a collective email address for the client to allow for continuing contact and support of the client software after the developer moves on and someone else takes over that responsibility.
由于本规范中描述的协议几乎只处理有关软件的信息，而不是人的信息，因此其使用很少涉及隐私问题。值得注意的例外是第2节中定义的“联系人”字段，其中包含开发人员或负责客户端软件的其他方的联系信息。这些值旨在向最终用户显示，并可供授权服务器的管理员使用。因此，开发商可能希望提供一个电子邮件地址或其他明确专用于支持客户的联系信息，而不是使用其个人或专业地址。或者，开发人员可能希望为客户提供一个集体电子邮件地址，以便在开发人员离开并且其他人接管该责任后，继续联系和支持客户软件。
In general, the metadata for a client, such as the client name and software identifier, are common across all instances of a piece of client software and therefore pose no privacy issues for end-users. Client identifiers, on the other hand, are often unique to a specific instance of a client. For clients such as web sites that are used by many users, there may not be significant privacy concerns regarding the client identifier, but for clients such as native applications that are installed on a single end-user's device, the client identifier could be uniquely tracked during OAuth 2.0 transactions and its use tied to that single end-user. However, as the client software still needs to be authorized by a resource owner through an OAuth 2.0 authorization grant, this type of tracking can occur whether or not the client identifier is unique by correlating the authenticated resource owner with the requesting client identifier.
通常，客户端的元数据（如客户端名称和软件标识符）在客户端软件的所有实例中都是通用的，因此不会对最终用户造成隐私问题。另一方面，客户机标识符通常对于客户机的特定实例是唯一的。对于许多用户使用的诸如网站之类的客户端，可能不存在关于客户端标识符的重大隐私问题，但是对于诸如安装在单个最终用户设备上的本机应用程序之类的客户端，在OAuth 2.0事务期间可以唯一地跟踪客户机标识符，并将其使用绑定到单个最终用户。但是，由于客户机软件仍然需要由资源所有者通过OAuth 2.0授权授予进行授权，因此通过将经过身份验证的资源所有者与请求的客户机标识符相关联，无论客户机标识符是否唯一，都可以进行此类跟踪。
Note that clients are forbidden by this specification from creating their own client identifier. If the client were able to do so, an individual client instance could be tracked across multiple colluding authorization servers, leading to privacy and security issues. Additionally, client identifiers are generally issued uniquely per registration request, even for the same instance of software. In this way, an application could marginally improve privacy by registering multiple times and appearing to be completely separate
请注意，此规范禁止客户端创建自己的客户端标识符。如果客户端能够这样做，则可以跨多个相互串通的授权服务器跟踪单个客户端实例，从而导致隐私和安全问题。此外，客户机标识符通常在每个注册请求中都是唯一发布的，即使对于相同的软件实例也是如此。通过这种方式，应用程序可以通过多次注册并看起来完全独立，从而略微改善隐私
applications. However, this technique does incur significant usability cost in the form of requiring multiple authorizations per resource owner and is therefore unlikely to be used in practice.
应用。然而，这种技术确实会产生巨大的可用性成本，即每个资源所有者需要多个授权，因此不太可能在实践中使用。
[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, <http://www.rfc-editor.org/info/bcp195>.
[BCP195]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 75252015年5月<http://www.rfc-editor.org/info/bcp195>.
[IANA.Language] IANA, "Language Subtag Registry", <http://www.iana.org/assignments/ language-subtag-registry>.
[IANA.Language]IANA，“语言子标签注册表”<http://www.iana.org/assignments/ 语言子标记注册表>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <http://www.rfc-editor.org/info/rfc5646>.
[RFC5646]Phillips，A.，Ed.和M.Davis，Ed.，“识别语言的标签”，BCP 47，RFC 5646，DOI 10.17487/RFC5646，2009年9月<http://www.rfc-editor.org/info/rfc5646>.
[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, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<http://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <http://www.rfc-editor.org/info/rfc6750>.
[RFC6750]Jones，M.和D.Hardt，“OAuth 2.0授权框架：承载令牌使用”，RFC 6750，DOI 10.17487/RFC6750，2012年10月<http://www.rfc-editor.org/info/rfc6750>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <http://www.rfc-editor.org/info/rfc7120>.
[RFC7120]Cotton，M.，“标准轨道代码点的早期IANA分配”，BCP 100，RFC 7120，DOI 10.17487/RFC7120，2014年1月<http://www.rfc-editor.org/info/rfc7120>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC7515]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<http://www.rfc-editor.org/info/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <http://www.rfc-editor.org/info/rfc7517>.
[RFC7517]Jones，M.，“JSON Web密钥（JWK）”，RFC 7517，DOI 10.17487/RFC75172015年5月<http://www.rfc-editor.org/info/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <http://www.rfc-editor.org/info/rfc7519>.
[RFC7519]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络令牌（JWT）”，RFC 7519，DOI 10.17487/RFC7519，2015年5月<http://www.rfc-editor.org/info/rfc7519>.
[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, <http://www.rfc-editor.org/info/rfc7522>.
[RFC7522]Campbell，B.，Mortimore，C.，和M.Jones，“OAuth 2.0客户端身份验证和授权授予的安全断言标记语言（SAML）2.0配置文件”，RFC 7522，DOI 10.17487/RFC7522，2015年5月<http://www.rfc-editor.org/info/rfc7522>.
[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, <http://www.rfc-editor.org/info/rfc7523>.
[RFC7523]Jones，M.，Campbell，B.，和C.Mortimore，“OAuth 2.0客户端身份验证和授权授权的JSON Web令牌（JWT）配置文件”，RFC 7523，DOI 10.17487/RFC7523，2015年5月<http://www.rfc-editor.org/info/rfc7523>.
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0", November 2014, <http://openid.net/specs/ openid-connect-discovery-1_0.html>.
[OpenID.Discovery]北樱村、J.布拉德利、M.琼斯和E.杰伊，“OpenID连接发现1.0”，2014年11月<http://openid.net/specs/ openid-connect-discovery-1_0.html>。
[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0", November 2014, <http://openid.net/specs/ openid-connect-registration-1_0.html>.
[OpenID.注册]Sakimura，N.，Bradley，J.，和M.Jones，“OpenID Connect动态客户端注册1.0”，2014年11月<http://openid.net/specs/ openid-connect-registration-1_0.html>。
[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, <http://www.rfc-editor.org/info/rfc7592>.
[RFC7592]Richer，J.，Jones，M.，Bradley，J.，和M.Machulak，“OAuth 2.0动态客户端注册管理协议”，RFC 7592，DOI 10.17487/RFC7592，2015年7月<http://www.rfc-editor.org/info/rfc7592>.
[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.
[UMA Core]Hardjono，T.，Maler，E.，Machulak，M.，和D.Catalano，“OAuth 2.0的用户管理访问（UMA）配置文件”，正在进行的工作，草稿-Hardjono-OAuth-umacore-13，2015年4月。
This appendix describes different ways that this specification can be utilized, including describing some of the choices that may need to be made. Some of the choices are independent and can be used in combination, whereas some of the choices are interrelated.
本附录描述了使用本规范的不同方式，包括描述可能需要做出的一些选择。有些选项是独立的，可以组合使用，而有些选项是相互关联的。
Authorization servers that support open registration allow registrations to be made with no initial access token. This allows all client software to register with the authorization server.
支持开放注册的授权服务器允许在没有初始访问令牌的情况下进行注册。这允许所有客户端软件向授权服务器注册。
Authorization servers that support protected registration require that an initial access token be used when making registration requests. While the method by which a client or developer receives this initial access token and the method by which the authorization server validates this initial access token are out of scope for this specification, a common approach is for the developer to use a manual preregistration portal at the authorization server that issues an initial access token to the developer.
支持受保护注册的授权服务器要求在发出注册请求时使用初始访问令牌。虽然客户端或开发人员接收此初始访问令牌的方法以及授权服务器验证此初始访问令牌的方法不在本规范的范围内，一种常见的方法是开发人员在授权服务器上使用手动预注册门户，向开发人员发出初始访问令牌。
When a software statement is not used in the registration request, the authorization server must be willing to use client metadata values without them being digitally signed or MACed (and thereby attested to) by any authority. (Note that this choice is independent of the Open versus Protected choice, and that an initial access token is another possible form of attestation.)
当注册请求中未使用软件语句时，授权服务器必须愿意使用客户端元数据值，而无需任何权威机构对其进行数字签名或MACE（从而证明）。（请注意，此选择独立于开放与受保护的选择，初始访问令牌是另一种可能的证明形式。）
A software statement can be used in a registration request to provide attestation by an authority for a set of client metadata values. This can be useful when the authorization server wants to restrict registration to client software attested to by a set of authorities or when it wants to know that multiple registration requests refer to the same piece of client software.
可以在注册请求中使用软件语句，以提供权威机构对一组客户端元数据值的证明。当授权服务器想要将注册限制在一组授权机构认证的客户端软件上，或者当它想要知道多个注册请求引用同一个客户端软件时，这可能很有用。
In some use cases, client software will dynamically register itself with an authorization server to obtain a client identifier and other information needed to interact with the authorization server. In this case, no client identifier for the authorization server is packaged with the client software.
在某些用例中，客户端软件将动态地向授权服务器注册，以获得客户端标识符和与授权服务器交互所需的其他信息。在这种情况下，授权服务器的客户端标识符不会与客户端软件打包在一起。
In some cases, the developer (or development software being used by the developer) will preregister the client software with the authorization server or a set of authorization servers. In this case, the client identifier value(s) for the authorization server(s) can be packaged with the client software.
在某些情况下，开发人员（或开发人员正在使用的开发软件）将向授权服务器或一组授权服务器预注册客户端软件。在这种情况下，授权服务器的客户端标识符值可以与客户端软件打包在一起。
In some cases, each deployed instance of a piece of client software will dynamically register and obtain distinct client identifier values. This can be advantageous, for instance, if the code flow is being used, as it also enables each client instance to have its own client secret. This can be useful for native clients, which cannot maintain the secrecy of a client secret value packaged with the software, but which may be able to maintain the secrecy of a per-instance client secret.
在某些情况下，客户端软件的每个已部署实例将动态注册并获得不同的客户端标识符值。例如，如果正在使用代码流，这可能是有利的，因为它还使每个客户机实例都有自己的客户机机密。这对于本机客户机很有用，本机客户机无法维护与软件打包的客户机机密值的机密性，但可以维护每个实例客户机机密的机密性。
In some cases, each deployed instance of a piece of client software will share a common client identifier value. For instance, this is often the case for in-browser clients using the implicit flow, when no client secret is involved. Particular authorization servers might choose, for instance, to maintain a mapping between software statement values and client identifier values, and return the same client identifier value for all registration requests for a particular piece of software. The circumstances under which an authorization server would do so, and the specific software statement characteristics required in this case, are beyond the scope of this specification.
在某些情况下，客户端软件的每个已部署实例将共享一个公共客户端标识符值。例如，对于使用隐式流的浏览器内客户机，当不涉及客户机机密时，通常会出现这种情况。例如，特定授权服务器可以选择维护软件语句值和客户端标识符值之间的映射，并为特定软件的所有注册请求返回相同的客户端标识符值。授权服务器执行此操作的情况以及本例中所需的特定软件语句特征超出了本规范的范围。
In some cases, authorization servers will maintain state about registered clients, typically indexing this state using the client identifier value. This state would typically include the client metadata values associated with the client registration, and possibly other state specific to the authorization server's implementation. When stateful registration is used, operations to support retrieving and/or updating this state may be supported. One possible set of operations upon stateful registrations is described in [RFC7592].
在某些情况下，授权服务器将维护已注册客户端的状态，通常使用客户端标识符值对该状态进行索引。此状态通常包括与客户机注册相关联的客户机元数据值，以及可能特定于授权服务器实现的其他状态。使用状态注册时，可能支持检索和/或更新此状态的操作。[RFC7592]中描述了一组可能的有状态注册操作。
In some cases, authorization servers will be implemented in a manner the enables them to not maintain any local state about registered clients. One means of doing this is to encode all the registration state in the returned client identifier value, and possibly encrypting the state to the authorization server to maintain the confidentiality and integrity of the state.
在某些情况下，授权服务器的实现方式将使它们能够不维护有关已注册客户端的任何本地状态。这样做的一种方法是在返回的客户机标识符值中对所有注册状态进行编码，并可能将该状态加密到授权服务器，以维护该状态的机密性和完整性。
Acknowledgments
致谢
The authors thank the OAuth Working Group, the User-Managed Access Working Group, and the OpenID Connect Working Group participants for their input to this document. In particular, the following individuals have been instrumental in their review and contribution to various draft versions of this document: 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, and Hannes Tschofenig.
作者感谢OAuth工作组、用户管理访问工作组和OpenID Connect工作组参与者对本文档的输入。特别是，以下个人对本文件的各种草案版本进行了审查和贡献：阿曼达·安加内斯、德里克·阿特金斯、蒂姆·布雷、多梅尼科·卡塔拉诺、唐纳德·科芬、弗拉基米尔·朱维诺夫、乔治·弗莱彻、托马斯·哈德乔诺、威廉·金、托尔斯滕·洛德斯特德、伊夫·马勒、乔什·曼德尔、诺夫·马塔克、，Tony Nadalin、Nat Sakimura、Christian Scholz和Hannes Tschofenig。
Authors' Addresses
作者地址
Justin Richer (editor)
贾斯汀·里希（编辑）
Email: ietf@justin.richer.org
Email: ietf@justin.richer.org
Michael B. Jones Microsoft
迈克尔·琼斯微软公司
Email: mbj@microsoft.com
URI: http://self-issued.info/
Email: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley Ping Identity
约翰·布拉德利·平身份
Email: ve7jtb@ve7jtb.com
Email: ve7jtb@ve7jtb.com
Maciej Machulak Newcastle University
纽卡斯尔大学
Email: maciej.machulak@gmail.com
Email: maciej.machulak@gmail.com
Phil Hunt Oracle Corporation
菲尔亨特甲骨文公司
Email: phil.hunt@yahoo.com
Email: phil.hunt@yahoo.com