Mutual TLS means the client presents a certificate as well as the server, so each side proves who it is during the handshake. It suits service to service traffic and high value APIs. RFC 8705 also uses it to bind OAuth access tokens to a client certificate so stolen tokens are useless alone.
How it differs from normal TLS
In ordinary TLS only the server authenticates. The client stays anonymous at the transport layer and proves itself later with a password, a token or a session cookie. With mTLS the server asks for a client certificate, checks it against a trusted issuer, and refuses the connection if it does not validate. Identity is established before any application data moves.
Where it fits
- Calls between internal services, where each workload gets a short lived certificate.
- Partner or B2B APIs where you want strong client identity.
- Regulated or high value endpoints where bearer tokens alone feel too weak.
- Device to cloud traffic where devices hold a key from manufacture.
It is a poor fit for open consumer apps, where you cannot issue a certificate to every user.
Two uses defined in RFC 8705
RFC 8705 defines two related OAuth mechanisms, usable separately or together.
Client authentication. The client proves itself to the authorization server with a certificate. There is a PKI method, where the chain must validate and the subject must match the registered value, and a self-signed method, where the client registers its certificates directly and the server checks for a match.
Certificate bound access tokens. The authorization server ties the token to the client certificate, typically by placing a SHA-256 thumbprint in the token or introspection response. The resource server checks that the certificate on the TLS connection matches. Otherwise it rejects with 401 and an invalid token error. This turns a bearer token into a proof of possession token: someone who steals the token cannot use it without the private key.
The RFC adds that before TLS 1.3 client certificates are sent unencrypted, which can enable tracking, and recommends TLS 1.3 for clients acting for a single user.
The operational cost
mTLS shifts work to certificate lifecycle. You need an issuer, a way to give each workload a certificate, rotation, revocation and monitoring. Short lived certificates reduce revocation needs but raise automation demands. See certificate renewal automation and how to stop expired certificate outages.
Public CAs are not always the right issuer for internal client certificates. Many teams use a private CA for workloads, which is a deliberate trust decision to document.
Checklist before you roll it out
- List the clients that need to connect and whether they can hold a private key safely.
- Choose an issuer and record who can issue.
- Decide lifetime and rotation, and automate it.
- Decide what the server checks beyond chain validity, such as the subject or SAN, so any certificate from your CA is not accepted for every client.
- Add logging of which certificate identity made each call.
- Test expired, revoked and wrong subject cases.
- Plan for debugging, since handshake failures are hard for developers to see.
Quick check
Does mTLS replace OAuth?
No. It can strengthen it, as in RFC 8705, or provide workload identity on its own. Authorization decisions still need a policy.
Is a self-signed client certificate acceptable?
RFC 8705 defines a self-signed method where certificates are registered directly, so it can work. It makes you responsible for tracking and rotating each registered certificate.
Sources
Last reviewed: 19 October 2026.
