OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
Extracted elements (30)
Certificate-bound access tokens issued via the implicit grant flow are explicitly out of scope because end users interact with the authorization endpoint via a web browser, and client certificates in browsers cause operational and usability problems (intrusive certificate selection UI).
Mutual-TLS client authentication and certificate-bound access tokens are explicitly specified as distinct, complementary mechanisms that do not need to be deployed or used together. This decoupling allows certificate binding at the resource server to serve purely as proof-of-possession, independent of how the client authenticated to the authorization server.
The 'mtls_endpoint_aliases' mechanism exists because a server requesting a TLS client certificate can cause undesirable behavior (e.g., intrusive certificate-selection prompts) for conventional browser-based clients; separate endpoints allow the server to apply mutual-TLS TLS behavior only to clients that intend to use it.
The access token cannot be used as input to the decision of whether to request mutual TLS at the resource server, because TLS CertificateRequest occurs during the handshake before Application Data (including the token) is available; resource servers must apply mutual TLS policy a priori.
The resource server does not need to validate the trust chain of the client's certificate in any method defined in this document, because proof-of-possession is decoupled from the client authentication method used at the authorization server; the resource server configures TLS to not verify CA signing.
A client using the 'tls_client_auth' authentication method MUST use exactly one of the defined metadata parameters (tls_client_auth_subject_dn, tls_client_auth_san_dns, tls_client_auth_san_uri, tls_client_auth_san_ip, tls_client_auth_san_email) to indicate the expected certificate subject.
An OAuth client intending to do mutual TLS MUST use the alias URL within 'mtls_endpoint_aliases' when present in preference to the endpoint URL of the same name at the top level of authorization server metadata.
For all requests to the authorization server utilizing mutual-TLS client authentication, the client MUST include the 'client_id' parameter so the authorization server can identify the client independently from the certificate content.
Protected resource access requests MUST be made over a mutually authenticated TLS connection using the same certificate that was used for mutual TLS at the token endpoint.
The authorization server MUST enforce the binding between client and certificate per Section 2.1 (PKI) or 2.2 (self-signed); if no certificate is presented or it doesn't match the expected one for the given client_id, the server returns an 'invalid_client' error.
The protected resource MUST obtain the client certificate from its TLS implementation layer and MUST verify it matches the certificate associated with the access token; a mismatch MUST result in HTTP 401 with 'invalid_token' error.
The TLS connection between the client and the authorization server MUST have been established or re-established with mutual-TLS X.509 certificate authentication, meaning the client Certificate and CertificateVerify messages are sent during the TLS handshake.
When access tokens are represented as JWTs, the certificate hash information SHOULD be represented using the 'x5t#S256' confirmation method member.
In TLS versions prior to 1.3, the client's certificate is sent unencrypted during the handshake and can be used by third parties to monitor, track, and correlate client activity. Clients acting on behalf of a single end user (e.g., native mobile apps) should use TLS 1.3 whenever possible to protect certificate privacy.
Five client registration metadata parameters are defined for the PKI method: tls_client_auth_subject_dn (RFC 4514 string of expected subject DN), tls_client_auth_san_dns (dNSName SAN), tls_client_auth_san_uri (uniformResourceIdentifier SAN), tls_client_auth_san_ip (IPv4 dotted-decimal or IPv6 colon-hex iPAddress SAN), and tls_client_auth_san_email (rfc822Name SAN).
For token introspection (RFC 7662), the hash of the certificate to which the token is bound is conveyed as a top-level 'cnf' member with 'x5t#S256' in the introspection response JSON, allowing the protected resource to verify proof-of-possession without embedding the hash in a JWT.
The authorization server metadata parameter 'tls_client_certificate_bound_access_tokens' (OPTIONAL, boolean, default false) signals server support for issuing mutual-TLS client certificate-bound access tokens.
The 'mtls_endpoint_aliases' authorization server metadata parameter is a JSON object containing alternative endpoint URLs (e.g., token_endpoint, revocation_endpoint, introspection_endpoint) that mutual-TLS-intending clients MUST prefer over the conventional top-level endpoints.
The PKI mutual-TLS method uses a validated certificate chain (RFC 5280) and a single subject DN or SAN to authenticate the client. The client is authenticated if the subject information matches the registered value; revocation checking is at the authorization server's discretion.
The Self-Signed Certificate method allows clients to authenticate using self-signed certificates registered via the 'jwks' or 'jwks_uri' metadata parameters, with the certificate represented in the 'x5c' parameter of the JWK. The server does not validate the certificate chain, only that the presented certificate matches a registered one.
The 'x5t#S256' JWT Confirmation Method member carries the X.509 Certificate SHA-256 Thumbprint as a base64url-encoded SHA-256 hash of the DER encoding of the certificate, nested within the 'cnf' claim of the JWT access token.
Registers 'cnf' (Confirmation) in the IANA 'OAuth Token Introspection Response' registry to allow proof-of-possession semantics (including 'x5t#S256') to be conveyed in introspection responses, extending RFC 7800 semantics to the introspection context.
Registers six client metadata parameters in the IANA 'OAuth Dynamic Client Registration Metadata' registry: 'tls_client_certificate_bound_access_tokens', 'tls_client_auth_subject_dn', 'tls_client_auth_san_dns', 'tls_client_auth_san_uri', 'tls_client_auth_san_ip', and 'tls_client_auth_san_email'.
Registers 'tls_client_certificate_bound_access_tokens' and 'mtls_endpoint_aliases' in the IANA 'OAuth Authorization Server Metadata' registry, and registers 'tls_client_auth' and 'self_signed_tls_client_auth' in the 'OAuth Token Endpoint Authentication Methods' registry.
Registers 'x5t#S256' (X.509 Certificate SHA-256 Thumbprint) in the IANA 'JWT Confirmation Methods' registry for JWT 'cnf' member values, as defined in Section 3.1.
For confidential clients using tls_client_auth or self_signed_tls_client_auth, refresh tokens are indirectly certificate-bound through the client_id and the requirement for certificate-based authentication. For public clients, the authorization server SHOULD explicitly bind the refresh token to the certificate and verify the binding on presentation.
SHA-256 was chosen for the certificate thumbprint binding because it provides sufficient second-preimage resistance to make it computationally infeasible to find a colliding certificate. If future hash algorithm changes are needed, new JWT Confirmation Method members should be defined and registered in the IANA 'JWT Confirmation Methods' registry.
When using the PKI method, an attacker could impersonate a client using a certificate with the same subject but from a different trusted CA. To mitigate this, the authorization server SHOULD only accept a limited set of CAs whose issuance policies meet its security requirements; otherwise, subject-based identification is vulnerable to certificate spoofing.
X.509 certificate parsing and validation is complex and has historically exposed security vulnerabilities; implementors SHOULD use an established and well-tested X.509 library and SHOULD NOT write their own certificate validation procedures. Key complexities include basic constraints, NUL bytes in ASN.1 strings, wildcard handling, and recursive chain verification.
The 'x5t#S256' value is a base64url-encoded (RFC 4648) SHA-256 hash of the DER-encoded (X.690) X.509 certificate; the encoded value MUST omit all trailing pad '=' characters and MUST NOT include any line breaks, whitespace, or other additional characters.