Mutual TLS gives an OAuth client and an authorization server a way to authenticate each other with X.509 certificates. RFC 8705 extends OAuth so a client can authenticate at the token endpoint with a certificate and an access token can be bound to the client's certificate. The result is a stronger machine credential than a shared client secret, provided every hop agrees on which certificate belongs to the request.
There are two related but separate controls. Client authentication at the token endpoint proves possession of the client certificate or a key associated with it. Certificate-bound access tokens carry a confirmation claim, commonly cnf with an x5t#S256 hash, that a protected resource compares with the certificate used on the request. A deployment that authenticates the client only when issuing a token but never checks the binding at the resource server has implemented half of the design.
TLS termination creates the hard engineering question. If a reverse proxy terminates mutual TLS, the application needs a trustworthy representation of the client certificate. A header containing the certificate or its hash must be stripped from inbound traffic and injected only by the trusted proxy after successful verification. The same rule applies to issuer, subject and serial attributes. Do not accept a client-supplied X-Forwarded-Client-Cert merely because the connection came through the ingress.
Certificate validation should be based on a configured trust anchor and an explicit identity rule. A valid chain proves that a certificate was issued under a trusted hierarchy, not that it represents the intended OAuth client. Map the certificate identity to the registered client, check revocation or short-lived certificate policy, and keep the mapping under change control. A wildcard that accepts every certificate from an internal CA is a shared trust domain, not per-client authentication.
Rotation needs a plan that does not depend on a single certificate. Publish the accepted trust anchors, define overlapping validity windows, test both old and new client certificates, and remove the old trust or client mapping after consumers have moved. Short-lived certificates reduce exposure but increase dependence on reliable enrollment and clock accuracy. Monitor expiry before the outage becomes the first signal.
Token binding also needs a resource-server test. Present a bound token over a connection whose certificate does not match the cnf claim and confirm rejection. Repeat through every proxy and service mesh path. Some proxies re-encrypt traffic and present a new certificate to the application. The application must know whether it is comparing the end-client certificate or an intermediary certificate that the authorization server intended to bind.
Audit records should identify the OAuth client and certificate fingerprint without storing private keys or full certificate blobs unless needed. When validation fails, distinguish an untrusted chain, a certificate for the wrong client, an expired certificate, a missing forwarded certificate, and a token without a confirmation claim. Those cases have different owners and remediation steps.
mTLS improves the authentication of software, not the authorization of the action it requests. Keep scopes, audience, resource-level authorization and rate limits. The certificate gives the service a reliable client identity to use in those decisions; it does not decide whether the client should read a tenant's data.