Wiki · Concept · Last reviewed June 25, 2026

OAuth Mutual TLS

OAuth mutual TLS is the RFC 8705 profile that uses X.509 client certificates for OAuth client authentication and for binding access tokens to the certificate holder.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, mutual TLS, mTLS, certificate-bound tokens

Definition

OAuth mutual TLS is defined in RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens. It describes client authentication at OAuth endpoints and access tokens bound to a client's mutual-TLS certificate.

The contrast is bearer-token use under RFC 6750. A bearer token can be used by whoever possesses the token string unless controls stop the request. A certificate-bound token adds holder-of-key evidence: the resource server must see the matching client certificate, not only the token.

For AI agents, the standard matters where server-side connectors or workload services act with OAuth authority. It can reduce replay risk and strengthen client authentication, but it does not decide whether an agent action was approved.

How It Works

In mutual TLS, the client presents an X.509 certificate during the TLS handshake and proves possession of the corresponding private key. RFC 8705 defines tls_client_auth, based on a validated PKI chain and registered subject information, and self_signed_tls_client_auth, based on a registered self-signed certificate or public key.

For certificate-bound access tokens, the authorization server binds the token to the client's certificate. A JWT access token can carry a cnf confirmation claim with x5t#S256, the SHA-256 thumbprint of the client certificate. If the token is opaque, token introspection can return the same confirmation material. The protected resource compares that thumbprint with the certificate presented on the TLS connection.

RFC 8705 also defines metadata. tls_client_certificate_bound_access_tokens indicates support for certificate-bound tokens, and mtls_endpoint_aliases can publish alternate endpoints for clients using mutual TLS.

Agent Context

Agent systems create long credential paths: a user approves a task, a model selects a tool, a runtime calls a connector, and a remote API receives the request. If the connector uses bearer tokens, a copied token from logs, traces, crash reports, or support bundles may replay the call. Mutual TLS adds a channel-bound possession check.

The fit is strongest for server-side agent infrastructure where certificate issuance, private-key custody, TLS termination, and resource-server configuration are controlled. It is less natural for casual browser agents or mobile clients where client certificates create deployment and privacy problems.

The control should be described accurately. Mutual TLS can authenticate the OAuth client and reduce replay. It cannot prove that a model chose the right tool, that the user understood a side effect, or that a prompt-injected workflow was harmless.

Governance and Safety

The first governance question is certificate custody: which system creates the private key, where it is stored, which connector can use it, what tenant or resource it represents, and how rotation works. A shared certificate across unrelated tools turns mTLS into another ambient service credential.

The second question is TLS termination. If a proxy terminates mutual TLS and forwards certificate details to an application server, resource servers need reliable access to the client-certificate evidence they are expected to validate.

The third question is certificate trust. RFC 8705 notes spoofing and validation complexity risks around X.509 processing. Authorization servers should constrain trusted certificate authorities and use established validation libraries.

Defense Pattern

Source Discipline

Claims about OAuth mutual TLS should name which RFC 8705 mechanism is in use: client authentication, certificate-bound access tokens, or both. A precise incident note should identify the client, certificate subject or thumbprint, token type, resource server, confirmation method, TLS termination point, and whether the request was replayed or made by the certificate holder.

Mutual TLS should not be collapsed into DPoP, PKCE, token exchange, refresh-token rotation, API keys, workload identity, or generic "zero trust."

Spiralist Reading

Spiralism reads OAuth mutual TLS as a demand that authority arrive with a body. The token is not allowed to wander alone; it must appear with the certificate holder that was bound to it.

That is custody evidence, not moral evidence. In agent systems, delegation becomes hard to reconstruct once tokens, tools, logs, and model outputs blur together. mTLS keeps one boundary legible.

Open Questions

Sources

Return to Wiki