RFC8705-OAuth 2.0双向TLS客户端身份验证和证书绑定访问令牌（OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens）（完结） - 《RFC中文翻译文档》

摘要
1. 简介（Introduction）
2. 用于OAuth客户端身份验证的双向TLS
- 2.1 PKI双向TLS方法
  - 2.1.1 PKI方法元数据值
  - 2.1.2 客户端注册的元数据
- 2.2 自签名证书双向TLS方法
  - 2.2.1 自签名方法元数据值
  - 2.2.2 客户端注册的元数据
3. 双向TLS客户端证书绑定访问令牌
4. 公共客户和证书绑定令牌
5. 双向TLS端点别名的元数据
6. 实施注意事项
7. 安全注意事项
8. 隐私注意事项
9. IANA注意事项
10. 参考文献
- 10.1 规范性引用
- 10.2 信息参考
附录A.示例“ cnf”声明，证书和JWK
附录B.与令牌绑定的关系

RFC8705-OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

摘要

本文档描述了OAuth客户端身份验证和证书绑定访问和刷新令牌使用X.509证书的双向传输层安全(TLS)身份验证。OAuth客户端基于自签名证书或公钥基础设施(PKI)，使用相互TLS为授权服务器提供了一种身份验证机制。为OAuth授权服务器提供了一种将访问令牌绑定到客户端的双向TLS证书的机制，并且为OAuth保护的资源提供了一种方法来确保提供给它的访问令牌被颁发给提供令牌的客户端。

This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security(TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client’s mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.

1. 简介（Introduction）

OAuth 2.0授权框架[RFC6749]允许第三方客户端应用程序获得对受保护资源的委托访问。在原型抽象OAuth流中，如图1所示，客户端从作为授权服务器的实体获得访问令牌，然后在访问受保护的资源如HTTPS APIs时使用该令牌。

The OAuth 2.0 Authorization Framework [RFC6749] enables third-party client applications to obtain delegated access to protected resources. In the prototypical abstract OAuth flow, illustrated in Figure 1, the client obtains an access token from an entity known as an authorization server and then uses that token when accessing protected resources, such as HTTPS APIs.

图1所示的流程包括以下步骤：
（A）

The flow illustrated in Figure 1 includes the following steps: (A) The client makes an HTTPS “POST” request to the authorization server and presents a credential representing the authorization grant. For certain types of clients (those that have been issued or otherwise established a set of client credentials) the request must be authenticated. In the response, the authorization server issues an access token to the client. (B) The client includes the access token when making a request to access a protected resource. (C) The protected resource validates the access token in order to authorize the request. In some cases, such as when the token is self-contained and cryptographically secured, the validation can be done locally by the protected resource. Other cases require that the protected resource call out to the authorization server to determine the state of the token and obtain metainformation about it.

2. 用于OAuth客户端身份验证的双向TLS

本部分定义为OAuth 2.0第2.3部分的扩展[RFC6749]，使用双向TLS X.509客户端的两种不同方法证书作为客户端凭据。双向TLS的要求客户端身份验证由授权服务器确定，基于给定客户端的策略或配置（无论客户端是否已动态注册，静态配置，或以其他方式建立）

This section defines, as an extension of Section 2.3 of OAuth 2.0 [RFC6749], two distinct methods of using mutual-TLS X.509 client certificates as client credentials. The requirement of mutual TLS for client authentication is determined by the authorization server, based on policy or configuration for the given client (regardless of whether the client was dynamically registered, statically configured, or otherwise established).

为了利用TLS进行OAuth客户端身份验证，必须通过双向TLS X.509证书身份验证(即在TLS握手期间发送客户端证书和证书认证消息)建立或重新建立客户端和授权服务器之间的TLS连接。

In order to utilize TLS for OAuth client authentication, the TLS connection between the client and the authorization server MUST have been established or re-established with mutual-TLS X.509 certificate authentication (i.e., the client Certificate and CertificateVerify messages are sent during the TLS handshake).

对于所有使用双向TLS客户端身份验证的授权服务器请求，客户端必须包含OAuth 2.0 [RFC6749]的2.2节中描述的“client_id”参数。参数“ client_id”的存在使授权服务器可以独立于证书的内容轻松地标识客户端。授权服务器可以使用客户端标识符找到客户端配置，并对照该客户端的预期凭据检查TLS握手中显示的证书。授权服务器必须执行客户端和证书之间的绑定，如以下第2.1或2.2节所述。如果没有提供证书，或者提供的证书与给定的“ client_id”期望的证书不匹配，则授权服务器将根据[RFC6749]的5.2节使用“ invalid_client”错误代码返回正常的OAuth 2.0错误响应指示客户端身份验证失败。

For all requests to the authorization server utilizing mutual-TLS client authentication, the client MUST include the “client_id” parameter described in Section 2.2 of OAuth 2.0 [RFC6749]. The presence of the “client_id” parameter enables the authorization server to easily identify the client independently from the content of the certificate. The authorization server can locate the client configuration using the client identifier and check the certificate presented in the TLS handshake against the expected credentials for that client. The authorization server MUST enforce the binding between client and certificate, as described in either Section 2.1 or 2.2 below. If no certificate is presented, or that which is presented doesn’t match that which is expected for the given “client_id”, the authorization server returns a normal OAuth 2.0 error response per Section 5.2 of [RFC6749] with the “invalid_client” error code to indicate failed client authentication.

2.1 PKI双向TLS方法

双向TLS OAuth客户端身份验证的PKI（公共密钥基础结构）方法遵循传统上将X.509证书用于身份验证的方式。它依靠经过验证的证书链[RFC5280]和单个主题专有名称（DN）或单个主题替代名称（SAN）来认证客户端。
每个客户端仅使用一个任何类型的主题名称值。TLS握手用于验证客户端拥有与证书中的公钥相对应的私钥，并验证相应的证书链。如果证书中的主题信息与为该特定客户端配置或注册的单个预期主题相匹配，则客户端将成功通过身份验证（请注意，在比较证书的DN值时，需要对DN值进行可预测的处理，例如[RFC4517]的distinguishedNameMatch规则。主题DN为客户的注册DN）。可以使用PKI方法进行吊销检查，但是是否以及如何检查证书的吊销状态是由授权服务器决定的部署决策。客户端可以通过从受信任的证书颁发机构（CA）获取具有相同主题的新证书来旋转X.509证书，而无需在授权服务器上修改相应的身份验证数据。

The PKI (public key infrastructure) method of mutual-TLS OAuth client authentication adheres to the way in which X.509 certificates are traditionally used for authentication. It relies on a validated certificate chain [RFC5280] and a single subject distinguished name (DN) or a single subject alternative name (SAN) to authenticate the client. Only one subject name value of any type is used for each client. The TLS handshake is utilized to validate the client’s possession of the private key corresponding to the public key in the certificate and to validate the corresponding certificate chain. The client is successfully authenticated if the subject information in the certificate matches the single expected subject configured or registered for that particular client (note that a predictable treatment of DN values, such as the distinguishedNameMatch rule from [RFC4517], is needed in comparing the certificate’s subject DN to the client’s registered DN). Revocation checking is possible with the PKI method but if and how to check a certificate’s revocation status is a deployment decision at the discretion of the authorization server. Clients can rotate their X.509 certificates without the need to modify the respective authentication data at the authorization server by obtaining a new certificate with the same subject from a trusted certificate authority (CA).

2.1.1 PKI方法元数据值

对于双向TLS客户端身份验证的PKI方法，本规范定义了以下身份验证方法元数据值并将其注册到“ OAuth令牌端点身份验证方法”注册表[IANA.OAuth.Parameters]中。
tls_client_auth
表示将使用将证书与客户端关联的PKI方法的双向TLS对授权服务器进行客户端认证。

For the PKI method of mutual-TLS client authentication, this specification defines and registers the following authentication method metadata value into the “OAuth Token Endpoint Authentication Methods” registry [IANA.OAuth.Parameters]. tls_client_auth Indicates that client authentication to the authorization server will occur with mutual TLS utilizing the PKI method of associating a certificate to a client.

2.1.2 客户端注册的元数据

为了传达证书的预期主题，为支持相互TLS客户端身份验证PK方法的OAuth 2.0动态客户端注册协议[RFC7591]引入了以下元数据参数。使用“ tls_client_auth”身份验证方法的客户端必须完全使用以下元数据参数之一来指示授权服务器在对相应客户端进行身份验证时期望的证书主题值。

In order to convey the expected subject of the certificate, the following metadata parameters are introduced for the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591] in support of the PKI method of mutual-TLS client authentication. A client using the “tls_client_auth” authentication method MUST use exactly one of the below metadata parameters to indicate the certificate subject value that the authorization server is to expect when authenticating the respective client.

tls_client_auth_subject_dn

OAuth客户端将在双向TLS身份验证中使用的证书的预期主题可分辨名称的字符串表示形式（如[RFC4514]中所定义）。

tls_client_auth_san_dns

一个字符串，其中包含OAuth客户端将在双向TLS身份验证中使用的证书中预期的dNSName SAN条目的值。

tls_client_auth_san_uri

一个字符串，其中包含OAuth客户端将在双向TLS身份验证中使用的证书中预期的统一资源标识符SAN条目的值。

tls_client_auth_san_ip

IP地址的字符串表示形式，可以是点分十进制表示法（对于IPv4）或冒号分隔的十六进制（对于IPv6，如[RFC5952]所定义），期望在OAuth证书中作为iP地址SAN条目存在客户端将在双向TLS身份验证中使用。根据[RFC5952]的第8节，此参数中的值与证书中的SAN条目的IP地址比较应以二进制格式进行。

tls_client_auth_san_email

一个字符串，其中包含OAuth客户端将在双向TLS身份验证中使用的证书中预期的rfc822 Name SAN条目的值。

tls_client_auth_subject_dn A string representation — as defined in [RFC4514] — of the expected subject distinguished name of the certificate that the OAuth client will use in mutual-TLS authentication. tls_client_auth_san_dns A string containing the value of an expected dNSName SAN entry in the certificate that the OAuth client will use in mutual-TLS authentication. tls_client_auth_san_uri A string containing the value of an expected uniformResourceIdentifier SAN entry in the certificate that the OAuth client will use in mutual-TLS authentication. tls_client_auth_san_ip A string representation of an IP address in either dotted decimal notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as defined in [RFC5952]) that is expected to be present as an iPAddress SAN entry in the certificate that the OAuth client will use in mutual-TLS authentication. Per Section 8 of [RFC5952], the IP address comparison of the value in this parameter and the SAN entry in the certificate is to be done in binary format. tls_client_auth_san_email A string containing the value of an expected rfc822Name SAN entry in the certificate that the OAuth client will use in mutual-TLS authentication.

2.2 自签名证书双向TLS方法

这种相互TLS OAuth客户端身份验证的方法旨在支持使用自签名证书的客户端身份验证。作为前提，客户端在授权服务器上注册其X.509证书（使用[RFC7591]中定义的“ jwks”）或对其X.509证书的可信源的引用（使用[RFC7591]中的“ jwks_uri”）。在身份验证期间，TLS用于验证客户端对与相应TLS握手中的证书中提供的公钥相对应的私钥的拥有。与PKI方法相反，在这种情况下，服务器不会验证客户端的证书链。如果客户端在握手过程中提供的证书与为该特定客户端配置或注册的证书之一匹配，则表示客户端已成功通过身份验证。自签名证书方法允许使用相互TLS来认证客户端，而无需维护PKI。当与客户端的“ jwks_uri”结合使用时，它还允许客户端旋转其X.509证书，而无需直接通过授权服务器更改其相应的身份验证数据。

This method of mutual-TLS OAuth client authentication is intended to support client authentication using self-signed certificates. As a prerequisite, the client registers its X.509 certificates (using “jwks” defined in [RFC7591]) or a reference to a trusted source for its X.509 certificates (using “jwks_uri” from [RFC7591]) with the authorization server. During authentication, TLS is utilized to validate the client’s possession of the private key corresponding to the public key presented within the certificate in the respective TLS handshake. In contrast to the PKI method, the client’s certificate chain is not validated by the server in this case. The client is successfully authenticated if the certificate that it presented during the handshake matches one of the certificates configured or registered for that particular client. The Self-Signed Certificate method allows the use of mutual TLS to authenticate clients without the need to maintain a PKI. When used in conjunction with a “jwks_uri” for the client, it also allows the client to rotate its X.509 certificates without the need to change its respective authentication data directly with the authorization server.

2.2.1 自签名方法元数据值

对于双向TLS客户端身份验证的自签名证书方法，此规范定义以下身份验证方法元数据值并将其注册到“ OAuth令牌端点身份验证方法”注册表[IANA.OAuth.Parameters]中。

self_signed_tls_client_auth

指示将使用相互TLS与使用自签名证书的客户端进行对授权服务器的客户端身份验证。

For the Self-Signed Certificate method of mutual-TLS client authentication, this specification defines and registers the following authentication method metadata value into the “OAuth Token Endpoint Authentication Methods” registry [IANA.OAuth.Parameters].

self_signed_tls_client_auth Indicates that client authentication to the authorization server will occur using mutual TLS with the client utilizing a self- signed certificate.

2.2.2 客户端注册的元数据

对于使用互tls客户端身份验证将证书与客户端绑定的自签名证书方法，使用[RFC7591]中现有的“jwks_uri”或“jwks”元数据参数在JWK集合[RFC7517]中通过JSON Web Key (JWK)传递客户端证书。“jwks”元数据参数是一个JWK集合，其中包含作为jwks数组的客户端公钥，而“jwks_uri”参数是一个引用客户端JWK集合的URL。证书是用集合中单个JWK的“x5c”参数表示的。注意，JWK中代表公钥的成员(例如，RSA中的“n”和“e”，椭圆曲线(EC)中的“x”和“y”)是每个[RFC7518]都需要的参数，所以它们将会出现，即使它们在这里没有被使用。还请注意，[RFC7517]的4.7节要求“x5c”参数的第一个证书中的密钥与JWK的其他成员所表示的公钥匹配。

For the Self-Signed Certificate method of binding a certificate with a client using mutual-TLS client authentication, the existing “jwks_uri” or “jwks” metadata parameters from [RFC7591] are used to convey the client’s certificates via JSON Web Key (JWK) in a JWK Set [RFC7517]. The “jwks” metadata parameter is a JWK Set containing the client’s public keys as an array of JWKs, while the “jwks_uri” parameter is a URL that references a client’s JWK Set. A certificate is represented with the “x5c” parameter of an individual JWK within the set. Note that the members of the JWK representing the public key (e.g., “n” and “e” for RSA, “x” and “y” for Elliptic Curve (EC)) are required parameters per [RFC7518] so will be present even though they are not utilized in this context. Also note that Section 4.7 of [RFC7517] requires that the key in the first certificate of the “x5c” parameter match the public key represented by those other members of the JWK.

3. 双向TLS客户端证书绑定访问令牌

当客户端在与令牌端点的连接上使用双向TLS时，授权服务器便能够将发出的访问令牌绑定到客户端证书。这样的绑定是通过将证书与令牌以一种可以由受保护资源访问的方式相关联来实现的，例如，使用第3.1节中描述的语法将证书哈希直接嵌入到已发布的访问令牌中，或者通过令牌自省如第3.2节所述。以这种方式将访问令牌绑定到客户端证书的好处是，可以将绑定与客户端与授权服务器的身份验证分离开来，这使得在受保护资源访问期间的双向TLS可以纯粹用作所有权证明机制。根据授权服务器和受保护资源达成的协议，将证书与访问令牌相关联的其他方法也是可行的，但超出了本规范的范围。

When mutual TLS is used by the client on the connection to the token endpoint, the authorization server is able to bind the issued access token to the client certificate. Such a binding is accomplished by associating the certificate with the token in a way that can be accessed by the protected resource, such as embedding the certificate hash in the issued access token directly, using the syntax described in Section 3.1, or through token introspection as described in Section 3.2. Binding the access token to the client certificate in that fashion has the benefit of decoupling that binding from the client’s authentication with the authorization server, which enables mutual TLS during protected resource access to serve purely as a proof-of-possession mechanism. Other methods of associating a certificate with an access token are possible, per agreement by the authorization server and the protected resource, but are beyond the scope of this specification.

为了使资源服务器使用证书绑定的访问令牌，必须预先了解双向TLS将用于部分或所有资源访问。特别是，访问令牌本身不能用作决定是否请求相互TLS的输入，因为（从TLS的角度来看）访问令牌本身是“应用程序数据”，仅在TLS握手完成后才进行交换，并且初始在应用程序数据可用之前，握手期间会发生证书请求。尽管可能会通过TLS 1.2重新协商[RFC5246]或TLS 1.3握手后身份验证[RFC8446]获得TLS客户端提供证书的后续机会，但本文档未对其用法作任何规定。可以预料，使用相互TLS的资源服务器将要求托管在其上的所有资源都使用相互TLS，或者将在单独的主机名和端口组合上提供受TLS相互保护的常规资源，尽管其他工作流程也是可能的。资源服务器策略与授权服务器（AS）同步的方式超出了本文档的范围。

In order for a resource server to use certificate-bound access tokens, it must have advance knowledge that mutual TLS is to be used for some or all resource accesses. In particular, the access token itself cannot be used as input to the decision of whether or not to request mutual TLS because (from the TLS perspective) it is “Application Data”, only exchanged after the TLS handshake has been completed, and the initial CertificateRequest occurs during the handshake, before the Application Data is available. Although subsequent opportunities for a TLS client to present a certificate may be available, e.g., via TLS 1.2 renegotiation [RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this document makes no provision for their usage. It is expected to be common that a mutual-TLS-using resource server will require mutual TLS for all resources hosted thereupon or will serve mutual-TLS-protected and regular resources on separate hostname and port combinations, though other workflows are possible. How resource server policy is synchronized with the authorization server (AS) is out of scope for this document.

在相互TLS保护的资源访问流的范围内，客户端发出受保护的资源请求，如[RFC6750]中所述，但是，这些请求必须在相互认证的TLS连接上发出，使用的证书与令牌端点上用于相互TLS的证书相同。

Within the scope of a mutual-TLS-protected resource-access flow, the client makes protected resource requests, as described in [RFC6750], however, those requests MUST be made over a mutually authenticated TLS connection using the same certificate that was used for mutual TLS at the token endpoint.

受保护的资源必须从其TLS实现层获取用于相互TLS的客户端证书，并且必须验证该证书是否与与访问令牌相关联的证书相匹配。如果它们不匹配，则必须按照[RFC6750]使用HTTP 401状态代码和“ invalid_token”错误代码来拒绝资源访问尝试，并产生错误。

The protected resource MUST obtain, from its TLS implementation layer, the client certificate used for mutual TLS and MUST verify that the certificate matches the certificate associated with the access token. If they do not match, the resource access attempt MUST be rejected with an error, per [RFC6750], using an HTTP 401 status code and the “invalid_token” error code.

第3.3节和第3.4节分别定义了传递服务器和客户端功能的元数据，用于相互tls客户端证书绑定访问令牌。

Metadata to convey server and client capabilities for mutual-TLS client certificate-bound access tokens is defined in Sections 3.3 and 3.4, respectively.

3.1 JWT证书指纹确认方法

当访问令牌表示为JSON Web Tokens(JWT) [RFC7519]时，证书哈希信息应该使用此处定义的“x5t#S256”确认方法成员表示。

When access tokens are represented as JSON Web Tokens (JWT) [RFC7519], the certificate hash information SHOULD be represented using the “x5t#S256” confirmation method member defined herein.

为了表示JWT中证书的哈希，本规范为X.509证书SHA-256指纹定义了新的JWT确认方法[RFC7800]成员“ x5t＃S256”。“ x5t＃S256”成员的值是X.509证书[RFC5280]的DER编码[X690]的base64url编码的[RFC4648] SHA-256 [SHS]哈希（aka，指纹，指纹或摘要） ]。以base64url编码的值必须忽略所有尾随的’=’字符，并且不得包含任何换行符，空格或其他附加字符。

To represent the hash of a certificate in a JWT, this specification defines the new JWT Confirmation Method [RFC7800] member “x5t#S256” for the X.509 Certificate SHA-256 Thumbprint. The value of the “x5t#S256” member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash (a.k.a., thumbprint, fingerprint, or digest) of the DER encoding [X690] of the X.509 certificate [RFC5280]. The base64url-encoded value MUST omit all trailing pad ‘=’ characters and MUST NOT include any line breaks, whitespace, or other additional characters.

以下是包含“ x5t＃S256”证书指纹确认方法的JWT有效负载的示例。这个规范引入的新的JWT内容是示例底部的“cnf”确认方法声明，它具有“x5t#S256”确认方法成员，该成员包含的值是绑定访问令牌的客户端证书的哈希值。
{
“iss”: “https://server.example.com“,
“sub”: “ty.webb@example.com”,
“exp”: 1493726400,
“nbf”: 1493722800,
“cnf”:{
“x5t#S256”: “bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2”
}
}

The following is an example of a JWT payload containing an “x5t#S256” certificate thumbprint confirmation method. The new JWT content introduced by this specification is the “cnf” confirmation method claim at the bottom of the example that has the “x5t#S256” confirmation method member containing the value that is the hash of the client certificate to which the access token is bound.
 {
   "iss": "https://server.example.com",
   "sub": "ty.webb@example.com",
   "exp": 1493726400,
   "nbf": 1493722800,
   "cnf":{
     "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
   }
 }
Figure 2: Example JWT Claims Set with an X.509 Certificate Thumbprint Confirmation Method

3.2 令牌自省的确认方法

OAuth 2.0令牌自省[RFC7662]定义了一种用于受保护资源的方法，用于向授权服务器查询有关访问令牌的活动状态以及确定有关令牌的元信息。

OAuth 2.0 Token Introspection [RFC7662] defines a method for a protected resource to query an authorization server about the active state of an access token as well as to determine metainformation about the token.

对于双向TLS客户端证书绑定的访问令牌，令牌绑定到的证书的哈希作为令牌自省响应中的元信息传送到受保护的资源。使用具有“ x5t＃S256”成员结构的相同“ cnf”作为证书SHA-256指纹确认方法（在3.1节中进行了描述）作为自省响应JSON的顶级成员来传递哈希。受保护的资源会将证书哈希与用于双向TLS身份验证的客户端证书的哈希进行比较，如果不匹配，则拒绝该请求。

For a mutual-TLS client certificate-bound access token, the hash of the certificate to which the token is bound is conveyed to the protected resource as metainformation in a token introspection response. The hash is conveyed using the same “cnf” with “x5t#S256” member structure as the certificate SHA-256 thumbprint confirmation method, described in Section 3.1, as a top-level member of the introspection response JSON. The protected resource compares that certificate hash to a hash of the client certificate used for mutual- TLS authentication and rejects the request if they do not match.

以下是使用“ x5t＃S256”证书指纹确认方法对活动令牌进行自省响应的示例。此规范引入的新的自省响应内容是示例底部的“cnf”确认方法，该方法具有“x5t#S256”确认方法成员，其中包含的值是绑定访问令牌的客户端证书的散列值。

The following is an example of an introspection response for an active token with an “x5t#S256” certificate thumbprint confirmation method. The new introspection response content introduced by this specification is the “cnf” confirmation method at the bottom of the example that has the “x5t#S256” confirmation method member containing the value that is the hash of the client certificate to which the access token is bound.
 HTTP/1.1 200 OK
 Content-Type: application/json
 {
   "active": true,
   "iss": "https://server.example.com",
   "sub": "ty.webb@example.com",
   "exp": 1493726400,
   "nbf": 1493722800,
   "cnf":{
     "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
   }
 }
  Figure 3: Example Introspection Response for a Certificate-Bound
                            Access Token

3.3 授权服务器元数据

本文档介绍了以下新的授权服务器元数据[RFC8414]参数，以指示服务器发布证书绑定的访问令牌的能力：

tls_client_certificate_bound_access_tokens

可选的。布尔值，用于指示客户端使用双向TLS客户端证书绑定的访问令牌的意图。如果省略，则默认值为“ false”。

This document introduces the following new authorization server metadata [RFC8414] parameter to signal the server’s capability to issue certificate-bound access tokens:

tls_client_certificate_bound_access_tokens OPTIONAL. Boolean value indicating server support for mutual-TLS client certificate-bound access tokens. If omitted, the default value is “false”.

3.4 客户注册元数据

引入了以下新的客户端元数据参数，以传达客户端使用证书绑定的访问令牌的意图:

tls_client_certificate_bound_access_tokens

可选的。布尔值，用于指示客户端使用双向TLS客户端证书绑定的访问令牌的意图。如果省略，则默认值为“ false”。

The following new client metadata parameter is introduced to convey the client’s intention to use certificate-bound access tokens:

tls_client_certificate_bound_access_tokens OPTIONAL. Boolean value used to indicate the client’s intention to use mutual-TLS client certificate-bound access tokens. If omitted, the default value is “false”.

请注意，如果指示使用双向TLS客户端证书绑定令牌的意图的客户端通过非双向TLS连接向令牌端点发出请求，则授权服务器将决定是否返回错误。或发行未绑定的令牌。

Note that if a client that has indicated the intention to use mutual- TLS client certificate-bound tokens makes a request to the token endpoint over a non-mutual-TLS connection, it is at the authorization server’s discretion as to whether to return an error or issue an unbound token.

4. 公共客户和证书绑定令牌

相互TLS OAuth客户端身份验证和证书绑定的访问令牌可以彼此独立使用。例如，在没有双向TLS OAuth客户端身份验证的情况下使用证书绑定的访问令牌，可以支持将访问令牌绑定到公共客户端(那些没有与“client_id”关联的身份验证凭证的客户端)的TLS客户端证书。授权服务器将以与“自签名证书”方法相同的方式配置TLS堆栈，以使其不验证客户端在握手期间提供的证书是否由受信任的CA签名。客户端的各个实例将与授权服务器和资源服务器创建用于相互TLS的自签名证书。授权服务器将不会使用双向TLS证书在OAuth层上对客户端进行身份验证，而是会将发出的访问令牌绑定到客户端已证明拥有相应私钥的证书。然后，将访问令牌绑定到证书，并且只有拥有证书和相应私钥的客户端才能使用访问令牌，并利用它们来协商与资源服务器的连接上的相互TLS。当授权服务器向这样的客户端发出刷新令牌时，它还应该将刷新令牌绑定到相应的证书，并在使用刷新令牌时检查绑定以获取新的访问令牌。刷新令牌绑定的实现细节由授权服务器决定。

Mutual-TLS OAuth client authentication and certificate-bound access tokens can be used independently of each other. Use of certificate- bound access tokens without mutual-TLS OAuth client authentication, for example, is possible in support of binding access tokens to a TLS client certificate for public clients (those without authentication credentials associated with the “client_id”). The authorization server would configure the TLS stack in the same manner as for the Self-Signed Certificate method such that it does not verify that the certificate presented by the client during the handshake is signed by a trusted CA. Individual instances of a client would create a self- signed certificate for mutual TLS with both the authorization server and resource server. The authorization server would not use the mutual-TLS certificate to authenticate the client at the OAuth layer but would bind the issued access token to the certificate for which the client has proven possession of the corresponding private key. The access token is then bound to the certificate and can only be used by the client possessing the certificate and corresponding private key and utilizing them to negotiate mutual TLS on connections to the resource server. When the authorization server issues a refresh token to such a client, it SHOULD also bind the refresh token to the respective certificate and check the binding when the refresh token is presented to get new access tokens. The implementation details of the binding of the refresh token are at the discretion of the authorization server.

5. 双向TLS端点别名的元数据

协商基于客户端证书的相互TLS的过程涉及TLS服务器从TLS客户端请求证书（客户端不提供一个未经请求的证书）。尽管可以将服务器配置为客户端证书是可选的，这意味着当客户端不提供证书时允许连接继续，但是服务器请求证书的行为可能导致某些客户端的不良行为。对于作为TLS客户端的Web浏览器尤其如此，当服务器请求证书时，该浏览器通常会向最终用户提供侵入式证书选择界面。

The process of negotiating client certificate-based mutual TLS involves a TLS server requesting a certificate from the TLS client (the client does not provide one unsolicited). Although a server can be configured such that client certificates are optional, meaning that the connection is allowed to continue when the client does not provide a certificate, the act of a server requesting a certificate can result in undesirable behavior from some clients. This is particularly true of web browsers as TLS clients, which will typically present the end user with an intrusive certificate selection interface when the server requests a certificate.

支持使用双向TLS的客户端和常规客户端的授权服务器可以选择将服务器端的双向TLS行为隔离到仅打算进行双向TLS的客户端，从而避免了对常规客户端可能产生的任何不良影响。引入了以下授权服务器元数据参数以促进这种分离：

mtls_endpoint_aliases

可选的。包含备用授权服务器端点的JSON对象，当存在该授权服务器端点时，打算进行双向TLS的OAuth客户端优先于常规端点使用。参数值本身包含一个或多个端点参数，例如“令牌令牌端点”，“吊销端点”，“自检端点”等，通常为授权服务器元数据的顶级定义。直接向授权服务器发出请求时，打算进行双向TLS（用于OAuth客户端身份验证和/或获取或使用证书绑定令牌）的OAuth客户端必须使用“ mtls_endpoint_aliases”中端点的别名URL（如果存在），而不是元数据顶层的同名端点URL。当“ mtls_endpoint_aliases”中不存在端点时，客户端将使用在授权服务器元数据的顶层定义的常规端点URL。未定义OAuth客户端向其直接请求的端点的“ mtls_endpoint_aliases”中的元数据参数没有任何意义，应忽略。

Authorization servers supporting both clients using mutual TLS and conventional clients MAY chose to isolate the server side mutual-TLS behavior to only clients intending to do mutual TLS, thus avoiding any undesirable effects it might have on conventional clients. The following authorization server metadata parameter is introduced to facilitate such separation:

mtls_endpoint_aliases OPTIONAL. A JSON object containing alternative authorization server endpoints that, when present, an OAuth client intending to do mutual TLS uses in preference to the conventional endpoints. The parameter value itself consists of one or more endpoint parameters, such as “token_endpoint”, “revocation_endpoint”, “introspection_endpoint”, etc., conventionally defined for the top level of authorization server metadata. An OAuth client intending to do mutual TLS (for OAuth client authentication and/or to acquire or use certificate-bound tokens) when making a request directly to the authorization server MUST use the alias URL of the endpoint within the “mtls_endpoint_aliases”, when present, in preference to the endpoint URL of the same name at the top level of metadata. When an endpoint is not present in “mtls_endpoint_aliases”, then the client uses the conventional endpoint URL defined at the top level of the authorization server metadata. Metadata parameters within “mtls_endpoint_aliases” that do not define endpoints to which an OAuth client makes a direct request have no meaning and SHOULD be ignored.

以下是带有“ mtls_endpoint_aliases”参数的授权服务器元数据文档的示例，该参数指示令牌，吊销和自省端点的别名，打算进行相互TLS的OAuth客户端将优先于常规令牌，吊销和自省端点。注意，“mtls_endpoint_aliases”中的端点使用的主机与传统的端点不同，这允许授权服务器(通过TLS“server_name”扩展[RFC6066]或实际不同的主机)根据需要区分其TLS行为。

Below is an example of an authorization server metadata document with the “mtls_endpoint_aliases” parameter, which indicates aliases for the token, revocation, and introspection endpoints that an OAuth client intending to do mutual TLS would use in preference to the conventional token, revocation, and introspection endpoints. Note that the endpoints in “mtls_endpoint_aliases” use a different host than their conventional counterparts, which allows the authorization server (via TLS “server_name” extension [RFC6066] or actual distinct hosts) to differentiate its TLS behavior as appropriate.

{ “issuer”: “https://server.example.com“, “authorization_endpoint”: “https://server.example.com/authz“, “token_endpoint”: “https://server.example.com/token“, “introspection_endpoint”: “https://server.example.com/introspect“, “revocation_endpoint”: “https://server.example.com/revo“, “jwks_uri”: “https://server.example.com/jwks“, “response_types_supported”: [“code”], “response_modes_supported”: [“fragment”,”query”,”form_post”], “grant_types_supported”: [“authorization_code”, “refresh_token”], “token_endpoint_auth_methods_supported”: [“tls_client_auth”,”client_secret_basic”,”none”], “tls_client_certificate_bound_access_tokens”: true, “mtls_endpoint_aliases”: { “token_endpoint”: “https://mtls.example.com/token“, “revocation_endpoint”: “https://mtls.example.com/revo“, “introspection_endpoint”: “https://mtls.example.com/introspect“ } }
  Figure 4: Example Authorization Server Metadata with Mutual-TLS
                          Endpoint Aliases

6. 实施注意事项

6.1 授权服务器

授权服务器需要为其支持的OAuth客户端身份验证方法适当地设置其TLS配置。

The authorization server needs to set up its TLS configuration appropriately for the OAuth client authentication methods it supports.

支持双向TLS客户端身份验证和其他客户端身份验证方法或并行的公共客户端的授权服务器将使双向TLS为可选（即，在服务器请求客户端证书但客户端不发送握手证书后允许握手继续进行）。

An authorization server that supports mutual-TLS client authentication and other client authentication methods or public clients in parallel would make mutual TLS optional (i.e., allowing a handshake to continue after the server requests a client certificate but the client does not send one).

为了仅支持“自签名证书”方法，授权服务器将以不验证客户端在握手过程中提供的证书是否由受信任的CA证书签名的方式配置TLS堆栈。

In order to support the Self-Signed Certificate method alone, the authorization server would configure the TLS stack in such a way that it does not verify whether the certificate presented by the client during the handshake is signed by a trusted CA certificate.

如第3节所述，授权服务器将已颁发的访问令牌绑定到TLS客户端证书，这意味着它将仅为客户端已证明拥有相应私钥的证书颁发证书绑定令牌。

As described in Section 3, the authorization server binds the issued access token to the TLS client certificate, which means that it will only issue certificate-bound tokens for a certificate that the client has proven possession of the corresponding private key.

授权服务器还可以考虑在单独的主机名或端口上托管令牌端点和其他需要客户端身份验证的端点，以防止对其其他端点(例如授权端点)的TLS行为产生意外影响。如第5节所述，它可以通过在单独的主机或端口上提供一组独特的终结点来进一步隔离请求客户端证书的服务器的任何潜在影响,这些端点是用于执行相互TLS的客户机将优先使用的原始端点的别名。

The authorization server may also consider hosting the token endpoint and other endpoints requiring client authentication on a separate host name or port in order to prevent unintended impact on the TLS behavior of its other endpoints, e.g., the authorization endpoint. As described in Section 5, it may further isolate any potential impact of the server requesting client certificates by offering a distinct set of endpoints on a separate host or port, which are aliases for the originals that a client intending to do mutual TLS will use in preference to the conventional endpoints.

6.2 资源服务器

OAuth划分了角色和职责，以便资源服务器依赖于授权服务器来执行客户端身份验证并获得资源所有者（最终用户）授权。资源服务器根据客户端提供的访问令牌做出授权决策，但本身并不直接对客户端进行身份验证。访问令牌绑定到客户端证书的方式以及受保护资源验证拥有证明的方式将其与客户端用于与授权服务器进行身份验证的特定方法解耦。因此，在受保护资源访问期间的相互TLS可以纯粹用作所有权证明机制。这样，资源服务器就不必通过本文档中定义的任何方法来验证客户端证书的信任链。因此，资源服务器将以不验证客户端在握手过程中提供的证书是否由受信任的CA证书签名的方式配置TLS堆栈。

OAuth divides the roles and responsibilities such that the resource server relies on the authorization server to perform client authentication and obtain resource-owner (end-user) authorization. The resource server makes authorization decisions based on the access token presented by the client but does not directly authenticate the client per se. The manner in which an access token is bound to the client certificate and how a protected resource verifies the proof- of-possession decouples that from the specific method that the client used to authenticate with the authorization server. Mutual TLS during protected resource access can, therefore, serve purely as a proof-of-possession mechanism. As such, it is not necessary for the resource server to validate the trust chain of the client’s certificate in any of the methods defined in this document. The resource server would, therefore, configure the TLS stack in a way that it does not verify whether the certificate presented by the client during the handshake is signed by a trusted CA certificate.

6.3 证书过期和绑定访问令牌

如第3节所述，访问令牌绑定到特定的客户端证书，这意味着在受保护的资源访问中，相互TLS必须使用相同的证书。这也意味着当客户端更新证书时，访问令牌将失效，这可以与过期的访问令牌类似地进行处理，在过期的访问令牌中，客户端请求新的访问令牌（通常带有刷新令牌）并重试受保护的资源请求。

As described in Section 3, an access token is bound to a specific client certificate, which means that the same certificate must be used for mutual TLS on protected resource access. It also implies that access tokens are invalidated when a client updates the certificate, which can be handled similarly to expired access tokens where the client requests a new access token (typically with a refresh token) and retries the protected resource request.

6.4 隐式授予不受支持

This document describes binding an access token to the client
certificate presented on the TLS connection from the client to the
authorization server’s token endpoint, however, such binding of
access tokens issued directly from the authorization endpoint via the
implicit grant flow is explicitly out of scope. End users interact
directly with the authorization endpoint using a web browser, and the
use of client certificates in user’s browsers bring operational and
usability issues that make it undesirable to support certificate-
bound access tokens issued in the implicit grant flow.
Implementations wanting to employ certificate-bound access tokens
should utilize grant types that involve the client making an access
token request directly to the token endpoint (e.g., the authorization
code and refresh token grant types).

6.5 TLS终止

授权服务器或资源服务器可以选择在负载均衡器，反向代理或其他网络中介处终止TLS连接。在这种情况下，如何在中间人和应用程序服务器之间安全地传递客户端证书元数据是超出本规范范围的。

An authorization server or resource server MAY choose to terminate TLS connections at a load balancer, reverse proxy, or other network intermediary. How the client certificate metadata is securely communicated between the intermediary and the application server, in this case, is out of scope of this specification.

7. 安全注意事项

7.1 证书绑定刷新令牌

OAuth 2.0授权框架[RFC6749]要求授权服务器（AS）将刷新令牌绑定到颁发它们的客户端，并且在提供刷新令牌时，机密客户端（已与AS建立了身份验证凭据的机密客户端）必须向AS进行身份验证。因此，当使用客户端身份验证的“tls_client_auth”或“self_signed_tls_client_auth”方法向客户端发布刷新令牌时，刷新令牌通过客户端ID和与之相关的(基于证书的)身份验证需求间接地与证书绑定。第4节描述颁发给公共客户端(那些没有与“client_id”关联的身份验证凭据的客户端)的证书绑定刷新令牌。

The OAuth 2.0 Authorization Framework [RFC6749] requires that an authorization server (AS) bind refresh tokens to the client to which they were issued and that confidential clients (those having established authentication credentials with the AS) authenticate to the AS when presenting a refresh token. As a result, refresh tokens are indirectly certificate-bound by way of the client ID and the associated requirement for (certificate-based) authentication to the AS when issued to clients utilizing the “tls_client_auth” or “self_signed_tls_client_auth” methods of client authentication. Section 4 describes certificate-bound refresh tokens issued to public clients (those without authentication credentials associated with the “client_id”).

7.2 证书指纹绑定

在3.1节中指定的证书和访问令牌之间的绑定使用了证书的加密散列。它依赖于具有足够的第二原像抵抗性的哈希函数，从而使其在计算上难以找到或创建另一个产生相同哈希输出值的证书。之所以使用SHA-256哈希函数，是因为它可以满足上述要求，同时又可以广泛使用。如果将来需要使用SHA-256以外的哈希函数来计算证书指纹，则建议针对其他相关JWT确认方法，为此目的定义成员并在IANA“ JWT确认”中注册 JWT“ cnf”成员值的“方法”注册表[IANA.JWT.Claims]。

The binding between the certificate and access token specified in Section 3.1 uses a cryptographic hash of the certificate. It relies on the hash function having sufficient second-preimage resistance so as to make it computationally infeasible to find or create another certificate that produces to the same hash output value. The SHA-256 hash function was used because it meets the aforementioned requirement while being widely available. If, in the future, certificate thumbprints need to be computed using hash function(s) other than SHA-256, it is suggested that, for additional related JWT confirmation methods, members be defined for that purpose and registered in the IANA “JWT Confirmation Methods” registry [IANA.JWT.Claims] for JWT “cnf” member values.

关于各种算法的强度和可行攻击的社区知识可能会突然发生变化，经验表明，关于安全性的文档是时间点声明。

Community knowledge about the strength of various algorithms and feasible attacks can change suddenly, and experience shows that a document about security is a point-in-time statement. Readers are advised to seek out any errata or updates that apply to this document.

7.3 TLS版本和最佳做法

本文档适用于任何支持基于证书的客户端身份验证的TLS版本。此处同时引用了TLS 1.3 [RFC8446]和TLS 1.2 [RFC5246]，因为在撰写本文时，1.3是最新版本，而1.2是部署最广泛的版本。TLS的一般实现和安全注意事项（包括版本建议）可以在[BCP195]中找到。

This document is applicable with any TLS version supporting certificate-based client authentication. Both TLS 1.3 [RFC8446] and TLS 1.2 [RFC5246] are cited herein, because, at the time of writing, 1.3 is the newest version, while 1.2 is the most widely deployed. General implementation and security considerations for TLS, including version recommendations, can be found in [BCP195].

TLS证书验证（针对客户端和服务器证书）需要本地受信任的证书颁发机构（CA）的数据库。有关信任哪些CA以及如何做出信任确定的决定不在本文档的范围之内。

TLS certificate validation (for both client and server certificates) requires a local database of trusted certificate authorities (CAs). Decisions about what CAs to trust and how to make such a determination of trust are out of scope for this document.

7.4 X.509证书欺骗

如果使用客户端身份验证的PKI方法，则攻击者可能试图使用具有相同主题（DN或SAN）但由授权服务器信任的不同CA颁发的证书来模拟客户端。为了应对这种威胁，授权服务器只应接受证书颁发策略满足其安全要求的有限数量的CA作为信任锚。然后假设客户端和服务器在服务器用来创建和验证证书链的信任锚集上达成一致。没有这种假设，使用主题来识别客户端证书将使服务器容易遭受证书欺骗攻击。

If the PKI method of client authentication is used, an attacker could try to impersonate a client using a certificate with the same subject (DN or SAN) but issued by a different CA that the authorization server trusts. To cope with that threat, the authorization server SHOULD only accept, as trust anchors, a limited number of CAs whose certificate issuance policy meets its security requirements. There is an assumption then that the client and server agree out of band on the set of trust anchors that the server uses to create and validate the certificate chain. Without this assumption the use of a subject to identify the client certificate would open the server up to certificate spoofing attacks.

7.5 X.509证书解析和验证复杂性

X.509证书和证书链的解析和验证很复杂，并且错误实现以前曾暴露出安全漏洞。验证的复杂性包括（但不限于）[CX5P] [DCW] [RFC5280]：

检查基本约束，基本和扩展密钥使用约束，有效期以及关键扩展；
处理ASN.1计数长度字符串中的嵌入式NUL字节以及主题名称中的非规范或非规范化字符串表示形式；
处理主题名称中的通配符模式;
证书链的递归验证和检查证书吊销。

Parsing and validation of X.509 certificates and certificate chains is complex, and implementation mistakes have previously exposed security vulnerabilities. Complexities of validation include (but are not limited to) [CX5P] [DCW] [RFC5280]:

checking of basic constraints, basic and extended key usage constraints, validity periods, and critical extensions;

handling of embedded NUL bytes in ASN.1 counted-length strings and non-canonical or non-normalized string representations in subject names;

handling of wildcard patterns in subject names;

recursive verification of certificate chains and checking certificate revocation.

由于这些原因，实现者应使用经过测试的已建立的X.509库（例如已建立的TLS库使用的库）来验证X.509证书链，并且不应尝试编写自己的X.509证书验证过程。

For these reasons, implementors SHOULD use an established and well- tested X.509 library (such as one used by an established TLS library) for validation of X.509 certificate chains and SHOULD NOT attempt to write their own X.509 certificate validation procedures.

8. 隐私注意事项

在1.3之前的TLS版本中，客户端的证书在初始握手中未加密地发送，并且可能被第三方用来监视，跟踪和关联客户端活动。对于代表大量最终用户的客户端来说，这可能几乎没有什么问题，因为在整个客户端活动中无法区分单个用户的活动但是，代表单个最终用户执行操作的客户端（例如移动设备上的本机应用程序）应尽可能使用TLS版本1.3，或考虑在较早版本上使用双向TLS可能带来的隐私隐患。

In TLS versions prior to 1.3, the client’s certificate is sent unencrypted in the initial handshake and can potentially be used by third parties to monitor, track, and correlate client activity. This is likely of little concern for clients that act on behalf of a significant number of end users because individual user activity will not be discernible amidst the client activity as a whole. However, clients that act on behalf of a single end user, such as a native application on a mobile device, should use TLS version 1.3 whenever possible or consider the potential privacy implications of using mutual TLS on earlier versions.

9. IANA注意事项

9.1 JWT确认方法注册

根据本规范，以下值已在[RFC7800]建立的JWT“ cnf”成员值的IANA“ JWT确认方法”注册表[IANA.JWT.Claims]中注册。

Per this specification, the following value has been registered in the IANA “JWT Confirmation Methods” registry [IANA.JWT.Claims] for JWT “cnf” member values established by [RFC7800].

Confirmation Method Value: “x5t#S256” Confirmation Method Description: X.509 Certificate SHA-256 Thumbprint Change Controller: IESG Specification Document(s): Section 3.1 of RFC 8705

9.2 授权服务器元数据注册

根据此规范，以下值已在[RFC8414]建立的IANA“ OAuth授权服务器元数据”注册表[IANA.OAuth.Parameters]中注册。

Per this specification, the following values have been registered in the IANA “OAuth Authorization Server Metadata” registry [IANA.OAuth.Parameters] established by [RFC8414].

Metadata Name: “tls_client_certificate_bound_access_tokens” Metadata Description: Indicates authorization server support for mutual-TLS client certificate-bound access tokens. Change Controller: IESG Specification Document(s): Section 3.3 of RFC 8705

Metadata Name: “mtls_endpoint_aliases” Metadata Description: JSON object containing alternative authorization server endpoints, which a client intending to do mutual TLS will use in preference to the conventional endpoints. Change Controller: IESG Specification Document(s): Section 5 of RFC 8705

9.3 令牌端点认证方法注册

根据此规范，以下值已在[RFC7591]建立的IANA“ OAuth令牌端点身份验证方法”注册表[IANA.OAuth.Parameters]中注册。

Per this specification, the following values have been registered in the IANA “OAuth Token Endpoint Authentication Methods” registry [IANA.OAuth.Parameters] established by [RFC7591].

Token Endpoint Authentication Method Name: “tls_client_auth” Change Controller: IESG Specification Document(s): Section 2.1.1 of RFC 8705

Token Endpoint Authentication Method Name: “selfsigned_tls_client auth” Change Controller: IESG Specification Document(s): Section 2.2.1 of RFC 8705

9.4 令牌自省响应注册

“用于JSON Web令牌（JWT）的所有权证明密钥语义” [RFC7800]定义了“ cnf”（确认）声明，该声明使确认密钥信息可以在JWT中携带。但是，相同的所有权证明语义对于自省的访问令牌也很有用，由此受保护的资源获得确认密钥数据作为令牌自省响应的元信息，并使用该信息来验证所有权证明。因此，本规范使用“ cnf”结构为OAuth 2.0令牌自省[RFC7662]定义和注册了所有权证明语义。当包含在OAuth令牌自省响应的顶级成员中时，“ cnf”具有与[RFC7800]中定义的相同名称的声明相同的语义和格式。虽然此规范仅显式使用“ x5t＃S256”确认方法成员（请参见第3.2节），但它需要定义并注册更高级别的“ cnf”结构作为自省响应成员，以便定义和使用更具体的证书指纹确认方法。

“Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)” [RFC7800] defined the “cnf” (confirmation) claim that enables confirmation key information to be carried in a JWT. However, the same proof-of-possession semantics are also useful for introspected access tokens whereby the protected resource obtains the confirmation key data as metainformation of a token introspection response and uses that information in verifying proof-of-possession. Therefore, this specification defines and registers proof-of-possession semantics for OAuth 2.0 Token Introspection [RFC7662] using the “cnf” structure. When included as a top-level member of an OAuth token introspection response, “cnf” has the same semantics and format as the claim of the same name defined in [RFC7800]. While this specification only explicitly uses the “x5t#S256” confirmation method member (see Section 3.2), it needs to define and register the higher- level “cnf” structure as an introspection response member in order to define and use the more specific certificate thumbprint confirmation method.

这样，以下值已在[RFC7662]建立的IANA“ OAuth令牌自省响应”注册表[IANA.OAuth.Parameters]中注册。

As such, the following values have been registered in the IANA “OAuth Token Introspection Response” registry [IANA.OAuth.Parameters] established by [RFC7662].

Claim Name: “cnf” Claim Description: Confirmation Change Controller: IESG Specification Document(s): [RFC7800] and RFC 8705

9.5 动态客户端注册元数据注册

根据此规范，以下客户端元数据定义已在[RFC7591]建立的IANA“ OAuth动态客户端注册元数据”注册表[IANA.OAuth.Parameters]中进行了注册：

Per this specification, the following client metadata definitions have been registered in the IANA “OAuth Dynamic Client Registration Metadata” registry [IANA.OAuth.Parameters] established by [RFC7591]:

Client Metadata Name: “tls_client_certificate_bound_access_tokens” Client Metadata Description: Indicates the client’s intention to use mutual-TLS client certificate-bound access tokens. Change Controller: IESG Specification Document(s): Section 3.4 of RFC 8705

Client Metadata Name: “tls_client_auth_subject_dn” Client Metadata Description: String value specifying the expected subject DN of the client certificate. Change Controller: IESG Specification Document(s): Section 2.1.2 of RFC 8705

Client Metadata Name: “tls_client_auth_san_dns” Client Metadata Description: String value specifying the expected dNSName SAN entry in the client certificate. Change Controller: IESG Specification Document(s): Section 2.1.2 of RFC 8705

Client Metadata Name: “tls_client_auth_san_uri” Client Metadata Description: String value specifying the expected uniformResourceIdentifier SAN entry in the client certificate. Change Controller: IESG Specification Document(s): Section 2.1.2 of RFC 8705

Client Metadata Name: “tls_client_auth_san_ip” Client Metadata Description: String value specifying the expected iPAddress SAN entry in the client certificate. Change Controller: IESG Specification Document(s): Section 2.1.2 of RFC 8705

Client Metadata Name: “tls_client_auth_san_email” Client Metadata Description: String value specifying the expected rfc822Name SAN entry in the client certificate. Change Controller: IESG Specification Document(s): Section 2.1.2 of RFC 8705

10. 参考文献

10.1 规范性引用

安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议
[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,
[https://www.rfc-editor.org/info/bcp195](https://www.rfc-editor.org/info/bcp195).

Rfc中使用的关键词要求等级
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate
Requirement Levels”, BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
[https://www.rfc-editor.org/info/rfc2119](https://www.rfc-editor.org/info/rfc2119).

轻量级目录访问协议(LDAP): 可分辨名称的字符串表示形式
[RFC4514] Zeilenga, K., Ed., “Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names”,
RFC 4514, DOI 10.17487/RFC4514, June 2006,
[https://www.rfc-editor.org/info/rfc4514](https://www.rfc-editor.org/info/rfc4514).

Base16、Base32和Base64数据编码
[RFC4648] Josefsson, S., “The Base16, Base32, and Base64 Data
Encodings”, RFC 4648, DOI 10.17487/RFC4648, October 2006,
[https://www.rfc-editor.org/info/rfc4648](https://www.rfc-editor.org/info/rfc4648).

传输层安全性(TLS) 协议版本1.2
[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security
(TLS) Protocol Version 1.2”, RFC 5246,
DOI 10.17487/RFC5246, August 2008,
[https://www.rfc-editor.org/info/rfc5246](https://www.rfc-editor.org/info/rfc5246).

Internet X.509公钥基础设施证书和证书吊销列表(CRL) 简介
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, “Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile”, RFC 5280, DOI 10.17487/RFC5280, May 2008,
[https://www.rfc-editor.org/info/rfc5280](https://www.rfc-editor.org/info/rfc5280).

OAuth 2.0授权框架
[RFC6749] Hardt, D., Ed., “The OAuth 2.0 Authorization Framework”,
RFC 6749, DOI 10.17487/RFC6749, October 2012,
[https://www.rfc-editor.org/info/rfc6749](https://www.rfc-editor.org/info/rfc6749).

OAuth 2.0授权框架：承载令牌使用
[RFC6750] Jones, M. and D. Hardt, “The OAuth 2.0 Authorization
Framework: Bearer Token Usage”, RFC 6750,
DOI 10.17487/RFC6750, October 2012,
[https://www.rfc-editor.org/info/rfc6750](https://www.rfc-editor.org/info/rfc6750).

JWK
[RFC7517] Jones, M., “JSON Web Key (JWK)”, RFC 7517,
DOI 10.17487/RFC7517, May 2015,
[https://www.rfc-editor.org/info/rfc7517](https://www.rfc-editor.org/info/rfc7517).

JWT
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token
(JWT)”, RFC 7519, DOI 10.17487/RFC7519, May 2015,
[https://www.rfc-editor.org/info/rfc7519](https://www.rfc-editor.org/info/rfc7519).

OAuth 2.0动态客户端注册协议
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, “OAuth 2.0 Dynamic Client Registration Protocol”,
RFC 7591, DOI 10.17487/RFC7591, July 2015,
[https://www.rfc-editor.org/info/rfc7591](https://www.rfc-editor.org/info/rfc7591).
OAuth 2.0令牌自省
[RFC7662] Richer, J., Ed., “OAuth 2.0 Token Introspection”,
RFC 7662, DOI 10.17487/RFC7662, October 2015,
[https://www.rfc-editor.org/info/rfc7662](https://www.rfc-editor.org/info/rfc7662).

JSON Web Tokens(JWTs)的拥有证明关键语义
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, “Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)”,
RFC 7800, DOI 10.17487/RFC7800, April 2016,
[https://www.rfc-editor.org/info/rfc7800](https://www.rfc-editor.org/info/rfc7800).

RFC 2119关键字中大写与小写的歧义
[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, [https://www.rfc-editor.org/info/rfc8174](https://www.rfc-editor.org/info/rfc8174).

OAuth 2.0授权服务器元数据
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, “OAuth 2.0
Authorization Server Metadata”, RFC 8414,
DOI 10.17487/RFC8414, June 2018,
[https://www.rfc-editor.org/info/rfc8414](https://www.rfc-editor.org/info/rfc8414).

传输层安全 (TLS) 协议版本1.3
[RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol
Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018,
[https://www.rfc-editor.org/info/rfc8446](https://www.rfc-editor.org/info/rfc8446).

安全哈希标准
[SHS] National Institute of Standards and Technology (NIST),
“Secure Hash Standard (SHS)”, FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.

“信息技术-ASN.1编码规则:规范基本编码规则 (BER)，规范编码规则 (CER) 和区分编码规则(DER)
[X690] ITU-T, “Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)”, ITU-T Recommendation X.690, August 2015.

10.2 信息参考

[CX5P] Wong, D., “Common x509 certificate validation/creation
pitfalls”, September 2016,
<https://www.cryptologie.net/article/374/common-x509-
certificate-validationcreation-pitfalls>.

[DCW] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
D., and V. Shmatikov, “The Most Dangerous Code in the
World: Validating SSL Certificates in Non-Browser
Software”, DOI 10.1145/2382196.2382204, October 2012,
[http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf](http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf).

[IANA.JWT.Claims]
IANA, “JSON Web Token Claims”,
[https://www.iana.org/assignments/jwt](https://www.iana.org/assignments/jwt).

[IANA.OAuth.Parameters]
IANA, “OAuth Parameters”,
[https://www.iana.org/assignments/oauth-parameters](https://www.iana.org/assignments/oauth-parameters).

[OpenID.CIBA]
Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B.
Campbell, “OpenID Connect Client Initiated Backchannel
Authentication Flow - Core 1.0”, 16 January 2019,
<https://openid.net/specs/openid-client-initiated-
backchannel-authentication-core-1_0.html>.

[RFC4517] Legg, S., Ed., “Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules”, RFC 4517,
DOI 10.17487/RFC4517, June 2006,
[https://www.rfc-editor.org/info/rfc4517](https://www.rfc-editor.org/info/rfc4517).

[RFC5952] Kawamura, S. and M. Kawashima, “A Recommendation for IPv6
Address Text Representation”, RFC 5952,
DOI 10.17487/RFC5952, August 2010,
[https://www.rfc-editor.org/info/rfc5952](https://www.rfc-editor.org/info/rfc5952).

[RFC6066] Eastlake 3rd, D., “Transport Layer Security (TLS)
Extensions: Extension Definitions”, RFC 6066,
DOI 10.17487/RFC6066, January 2011,
[https://www.rfc-editor.org/info/rfc6066](https://www.rfc-editor.org/info/rfc6066).

[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, “OAuth
2.0 Token Revocation”, RFC 7009, DOI 10.17487/RFC7009,
August 2013, [https://www.rfc-editor.org/info/rfc7009](https://www.rfc-editor.org/info/rfc7009).

[RFC7518] Jones, M., “JSON Web Algorithms (JWA)”, RFC 7518,
DOI 10.17487/RFC7518, May 2015,
[https://www.rfc-editor.org/info/rfc7518](https://www.rfc-editor.org/info/rfc7518).

[TOKEN] Jones, M., Campbell, B., Bradley, J., and W. Denniss,
“OAuth 2.0 Token Binding”, Work in Progress, Internet-
Draft, draft-ietf-oauth-token-binding-08, 19 October 2018,
<https://tools.ietf.org/html/draft-ietf-oauth-token-
binding-08>.

附录A.示例“ cnf”声明，证书和JWK

作为参考，在下面的示例中分别提供了“ x5t＃S256”值和从中计算得出的X.509证书（图5和6）。图7还提供了证书的公钥以及“ x5c”成员的JWK表示形式。

For reference, an “x5t#S256” value and the X.509 certificate from which it was calculated are provided in the following examples, Figures 5 and 6, respectively. A JWK representation of the certificate’s public key along with the “x5c” member is also provided in Figure 7.

“cnf”:{“x5t#S256”:”A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0”}
               Figure 5: x5t#S256 Confirmation Claim
——-BEGIN CERTIFICATE——- MIIBBjCBrAIBAjAKBggqhkjOPQQDAjAPMQ0wCwYDVQQDDARtdGxzMB4XDTE4MTAx ODEyMzcwOVoXDTIyMDUwMjEyMzcwOVowDzENMAsGA1UEAwwEbXRsczBZMBMGByqG SM49AgEGCCqGSM49AwEHA0IABNcnyxwqV6hY8QnhxxzFQ03C7HKW9OylMbnQZjjJ /Au08/coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8wCgYIKoZIzj0EAwID SQAwRgIhAP0RC1E+vwJD/D1AGHGzuri+hlV/PpQEKTWUVeORWz83AiEA5x2eXZOV bUlJSGQgjwD5vaUaKlLR50Q2DmFfQj1L+SY= ——-END CERTIFICATE——-
           Figure 6: PEM Encoded Self-Signed Certificate
{ “kty”:”EC”, “x”:”1yfLHCpXqFjxCeHHHMVDTcLscpb07KUxudBmOMn8C7Q”, “y”:”8_coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8”, “crv”:”P-256”, “x5c”:[ “MIIBBjCBrAIBAjAKBggqhkjOPQQDAjAPMQ0wCwYDVQQDDARtdGxzMB4XDTE4MTA xODEyMzcwOVoXDTIyMDUwMjEyMzcwOVowDzENMAsGA1UEAwwEbXRsczBZMBMGBy qGSM49AgEGCCqGSM49AwEHA0IABNcnyxwqV6hY8QnhxxzFQ03C7HKW9OylMbnQZ jjJ/Au08/coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8wCgYIKoZIzj0E AwIDSQAwRgIhAP0RC1E+vwJD/D1AGHGzuri+hlV/PpQEKTWUVeORWz83AiEA5x2 eXZOVbUlJSGQgjwD5vaUaKlLR50Q2DmFfQj1L+SY=” ] }
                       Figure 7: JSON Web Key

附录B.与令牌绑定的关系

OAuth 2.0令牌绑定[TOKEN]支持将令牌绑定应用到整个OAuth中使用的各种工件和令牌。这包括将访问令牌绑定到令牌绑定密钥，该令牌在动机和设计上与本文档中定义的相互TLS客户端证书绑定的访问令牌具有一些相似之处。这两个文档都定义了通常称为访问令牌的所有权证明安全机制，由此客户端在访问受保护的资源时必须证明拥有加密密钥材料。这两个文档之间的详细信息有所不同，但是两者都有授权服务器将它颁发的访问令牌绑定到客户端持有的非对称密钥对。然后，客户端针对访问受保护资源的TLS连接证明该对拥有私钥。

OAuth 2.0 Token Binding [TOKEN] enables the application of Token Binding to the various artifacts and tokens employed throughout OAuth. That includes binding of an access token to a Token Binding key, which bears some similarities in motivation and design to the mutual-TLS client certificate-bound access tokens defined in this document. Both documents define what is often called a proof-of- possession security mechanism for access tokens, whereby a client must demonstrate possession of cryptographic keying material when accessing a protected resource. The details differ somewhat between the two documents but both have the authorization server bind the access token that it issues to an asymmetric key pair held by the client. The client then proves possession of the private key from that pair with respect to the TLS connection over which the protected resource is accessed.

令牌绑定使用在客户端上生成的裸键，从而避免了创建，分发和管理本规范中使用的证书的许多困难。但是，在撰写本文时，令牌绑定是相当新的，并且在可用的应用程序开发平台和工具中对此的支持相对较少。除非存在对基础核心令牌绑定规范的更好支持，否则OAuth 2.0令牌绑定的实际实现是不可行的。另一方面，相互TLS已经存在了一段时间，并且在Web服务器和开发平台中得到了广泛的支持。因此，现在可以使用现有平台和工具来构建和部署OAuth 2.0相互TLS客户端身份验证和证书绑定访问令牌。将来，可能会并行部署这两个规范，以解决不同环境中的类似问题。授权服务器甚至可以使用不同的所有权证明机制（同时为发布给不同客户端的令牌）同时支持两种规范。

Token Binding uses bare keys that are generated on the client, which avoids many of the difficulties of creating, distributing, and managing certificates used in this specification. However, at the time of writing, Token Binding is fairly new, and there is relatively little support for it in available application development platforms and tooling. Until better support for the underlying core Token Binding specifications exists, practical implementations of OAuth 2.0 Token Binding are infeasible. Mutual TLS, on the other hand, has been around for some time and enjoys widespread support in web servers and development platforms. As a consequence, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens can be built and deployed now using existing platforms and tools. In the future, the two specifications are likely to be deployed in parallel for solving similar problems in different environments. Authorization servers may even support both specifications simultaneously using different proof-of-possession mechanisms for tokens issued to different clients.

Acknowledgements

Scott “not Tomlinson” Tomilson and Matt Peterson were involved in design and development work on a mutual-TLS OAuth client authentication implementation that predates this document. Experience and learning from that work informed some of the content of this document.

This specification was developed within the OAuth Working Group under the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with Eric Rescorla, Benjamin Kaduk, and Roman Danyliw serving as Security Area Directors. Additionally, the following individuals contributed ideas, feedback, and wording that helped shape this specification: Vittorio Bertocci, Sergey Beryozkin, Ralph Bragg, Sophie Bremer, Roman Danyliw, Vladimir Dzhuvinov, Samuel Erdtman, Evan Gilman, Leif Johansson, Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko Kawasaki, Sean Leonard, Kepeng Li, Neil Madden, James Manger, Jim Manico, Nov Matake, Sascha Preibisch, Eric Rescorla, Justin Richer, Vincent Roca, Filip Skokan, Dave Tonge, and Hannes Tschofenig.

Authors’ Addresses

Brian Campbell Ping Identity

Email: brian.d.campbell@gmail.com

John Bradley Yubico

Email: ve7jtb@ve7jtb.com URI: http://www.thread-safe.com/

Nat Sakimura Nomura Research Institute

Email: n-sakimura@nri.co.jp URI: https://nat.sakimura.org/

Torsten Lodderstedt YES.com AG

Email: torsten@lodderstedt.net