Mutual TLS

Mutual TLS (mTLS) extends the ordinary TLS handshake so that both parties present and verify X.509 certificates: the client authenticates the server as usual, and the server also authenticates the client. That two-way check turns transport encryption into a strong, cryptographic form of client identity. RFC 8705 formalizes how mTLS is used for OAuth 2.0 client authentication and for binding access tokens to a client’s certificate.

• Two-way certificate verification - Both client and server prove identity with X.509 certificates during the handshake, not after.
• Certificate-bound access tokens - RFC 8705 lets an OAuth token be tied to the presenting client’s certificate, so a stolen token is useless without the matching key.
• No shared secrets on the wire - Authentication rests on private keys that never leave the client, unlike API keys pasted into headers or query strings.
• Operational cost - The trade-off is real certificate lifecycle work: issuance, rotation, revocation, and trust-store management.

In API operations, mTLS shows up wherever the identity of the calling client genuinely matters, most visibly in regulated open-banking stacks like the Australian CDR, where it is part of the required data-sharing baseline. It pairs naturally with OAuth 2.0 to raise both client authentication and token security well above query-string keys. When I score an API’s security posture, certificate-bound access is one of the clearest signals that a provider is operating at a mature, regulated-grade level.