RFC 8705 defines mutual-TLS client authentication and certificate-bound access tokens for OAuth. The client authenticates with an X.509 certificate, and the issued token is bound to it, so the token is only usable by the party that holds the private key.
Mutual TLS (mTLS) for OAuth
Mutual TLS (mTLS) for OAuth (RFC 8705) — RFC 8705 defines mutual-TLS client authentication and certificate-bound access tokens for OAuth. The client authenticates with an X.509 certificate, and the issued token is bound to it, so the token is only usable by the party that holds the private key.
- Client authentication and token binding - Two distinct capabilities in one specification.
- The FAPI baseline - Financial-grade profiles rely on mTLS or private_key_jwt rather than client secrets.
- Certificate-bound tokens - A stolen token is useless without the corresponding certificate.
- Infrastructure-heavy - Requires certificate issuance and rotation, which is why DPoP exists for lighter contexts.
mTLS is declared as a security scheme in 29 of 14,195 published API contracts — 0.2%. The State of Cybersecurity APIs and The OpenID Connect Standard both find the same pattern: providers running genuinely FAPI-grade security routinely describe it in the contract as a plain bearer token, so the rigour is real and invisible to any machine reading the description.
Referenced in API Evangelist papers
This standard shows up in my published research. These reports read the machine-readable evidence provider by provider — and put this standard in the context of a real sector.
The State of Cybersecurity APIs
Providers running FAPI-grade security routinely describe it in the contract as a plain bearer token.
The OAuth 2.0 Standard
Declared in 29 of 14,195 contracts — 0.2%.
