mTLSによる送信者制約付きトークン

A plain bearer token works for anyone who holds it. If it leaks via logs, a proxy, or an XSS bug, the thief can use it freely. Sender-constrained tokens fix this by binding the token to the legitimate client.

Mutual TLS means both sides present certificates: the server proves its identity (as usual) and the client also presents a certificate. The authorization server can then bind issued tokens to that client certificate.

This is standardized in RFC 8705 (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens). It covers both client authentication via mTLS and certificate binding of access tokens.

When the AS issues a certificate-bound token, it records a confirmation (cnf) claim containing the SHA-256 thumbprint of the client certificate under the key x5t#S256.

When the client calls an API over mTLS, the resource server computes the thumbprint of the presented certificate and compares it to the token's cnf.x5t#S256. If they differ, the token is rejected.

Even with the token, an attacker cannot present the client's private key, so they cannot complete the mTLS handshake with the matching certificate. The thumbprint will not match, and the API rejects them.

RFC 8705 also lets clients authenticate at the token endpoint with their certificate instead of a shared secret, using methods tls_client_auth (PKI) or self_signed_tls_client_auth.

Because mTLS needs a separate TLS configuration, providers publish mtls_endpoint_aliases in discovery so clients hit the certificate-bound versions of the token and other endpoints.

Both achieve sender-constraint:

• mTLS — relies on TLS-layer certificates, great for server-to-server and infrastructure with PKI.
• DPoP — application-layer proof JWTs, better for browser/public clients that cannot manage client certs.

mTLS requires certificate provisioning, rotation, and a TLS terminator that forwards the client cert to your app. Plan for cert lifecycle and ensure your reverse proxy passes the verified certificate to the resource server.

Choose mTLS-bound tokens for high-assurance, regulated, or financial-grade APIs and trusted backend services where certificate management is feasible. It dramatically raises the cost of token theft.

mTLS sender-constrained tokens (RFC 8705) bind a token to the client's certificate.

• The token carries a cnf.x5t#S256 certificate thumbprint.
• Resource servers match the presented cert's thumbprint; a stolen token without the private key fails.
• mTLS also enables certificate-based client authentication and uses mtls endpoint aliases.
• Compare with DPoP for public clients.