skip to content

In RFC 8705 section 2, how do tls_client_auth and self_signed_tls_client_auth authenticate an OAuth 2.0 client differently?

level: seniorimportance: nice to knowfreq 27%

answer

  1. the certificate is the credential
  2. client_id is still in the request
  3. one trusts an issuer, one trusts a certificate
  4. exactly one registered subject parameter
  5. chain plus subject match, or exact match

basics

~20 s

Both authenticate the client by the certificate it presents on a mutual-TLS connection to the token endpoint. tls_client_auth checks a trusted-issuer certificate against one registered subject value; self_signed_tls_client_auth matches it against the registered key set.

solid answer

~40 s

In both methods the credential is the certificate presented during the TLS handshake, and the client still sends `client_id` in the token request — the certificate is the credential, not the identifier. `tls_client_auth` is the PKI-based variant: the certificate must chain to an issuer the authorization server trusts, and the registration declares **exactly one** expected subject value, such as `tls_client_auth_subject_dn` (the full distinguished name) or `tls_client_auth_san_dns` (a DNS entry in the subject alternative name). The server compares the presented certificate's corresponding field with that one registered value. `self_signed_tls_client_auth` needs no certificate authority at all: the client registers its certificate in its own key set, and the server checks that the certificate presented matches a registered one. Rotation differs accordingly — reissue under the same subject, versus updating the registered key set.

code

json · 6 lines
json
{
  "client_id": "s6BhdRkqt3",
  "token_endpoint_auth_method": "tls_client_auth",
  "tls_client_auth_san_dns": "filings.broker.example.com",
  "grant_types": ["client_credentials"]
}

go deeper

for a junior

Recall the shape: the client proves itself with a certificate on the connection rather than with a secret in the request, and the authorization server compares that certificate with something it registered earlier.

for a middle

Explain the two comparisons — trusted issuer plus one registered subject value, versus an exact match against a registered certificate — and that client_id is still sent either way.

for a senior

Show the failure modes: a trusted authority with no subject check, a terminating proxy that never requests the certificate, a request sent to the endpoint that does not ask for one, and expiry treated as an unscheduled outage.

for a principal

The decision you own is whether the organisation can run certificate lifecycles per integration at all; where it already does, this removes reusable credentials, and where it does not, it adds a renewal failure that looks like an outage.

## Both methods start from the same handshake RFC 8705 §2 defines two ways to authenticate an OAuth 2.0 client with a certificate. Both require the token request to arrive over a TLS connection in which the client also presented a certificate, and both register as values of `token_endpoint_auth_method`. What differs is **what the authorization server compares that certificate against**. What does *not* differ: the `client_id` is still sent in the token request. The certificate proves possession of a key; it does not by itself tell the server which registration the caller means. ## `tls_client_auth` — the PKI-based variant Here the authorization server trusts an issuing certificate authority, and the client's registration records the single subject value the server should expect. RFC 8705 §2 defines a small set of subject-identifier metadata parameters for that purpose — `tls_client_auth_subject_dn` for the full distinguished name of the certificate's subject, and alternatives keyed on entries in the subject alternative name, such as `tls_client_auth_san_dns` — and requires the registration to use **exactly one** of them. The check is then two-part: 1. the presented certificate is valid and issued by a trusted authority, per ordinary certificate path validation; 2. the field named by the registered parameter equals the registered value exactly. Both halves matter. Trusting the issuer without comparing the subject means any certificate from that authority authenticates any client — a live failure mode wherever a widely used commercial authority is in the trust list. Comparing the subject without validating the chain means anyone can assert the name. ## `self_signed_tls_client_auth` — no authority at all The second variant removes the certificate authority from the picture. The client registers its certificate directly, in the key set that the client's metadata publishes or points at, and the authorization server authenticates by checking that the certificate presented in the handshake matches one already registered. There is no issuer to trust and no subject value to compare, because the certificate itself is the registered credential. | | `tls_client_auth` | `self_signed_tls_client_auth` | |---|---|---| | Trust comes from | an issuing certificate authority the server trusts | the registered certificate itself | | Registered metadata | exactly one subject value, e.g. `tls_client_auth_san_dns` | the client's key set containing the certificate | | The server's check | valid chain **and** the subject field matches | the presented certificate matches a registered one | | Rotation | reissue under the same subject; no registration change | update the registered key set before switching | | Failure if you skip a step | any certificate from that authority is accepted | none — there is no chain to get wrong | ## Why an integration reaches for this at all In a business-to-business integration the counterparty is a server with a real, administered identity, often one already carrying a certificate for other reasons. Certificate-based client authentication then gives what a shared secret cannot: nothing reusable is transmitted, the credential is bound to a private key the caller never sends, and revoking or reissuing follows a lifecycle the operator already runs. The operational cost is honest and worth stating: a private key has to live somewhere the service can read at start-up, expiry is a scheduled outage if nobody watches it, and a proxy that terminates TLS in front of the authorization server has to convey the presented certificate onward or the method silently cannot work. ## Two things this is not - **It is not the same as binding an issued token to the certificate.** RFC 8705 defines that separately, in a later section, as a distinct mechanism with its own metadata; authenticating the client at the token endpoint and constraining what is later done with the token are different questions. - **It is not a statement about the handshake or path validation.** Which peer proves what during a mutually authenticated TLS handshake, and how a chain is built and checked, belong to the transport and certificate specifications rather than to OAuth 2.0. ## Discovering support As with every other method, the authorization server publishes what it accepts in `token_endpoint_auth_methods_supported`. Servers that offer mutual-TLS methods frequently expose them on a separate host or port so that only those endpoints request a client certificate, and advertise that separate set in `mtls_endpoint_aliases` — a client that posts to the ordinary token endpoint instead will never be asked for a certificate and will fail authentication with a perfectly valid one installed.

  • An authorization server trusts a widely used commercial certificate authority and checks only that the client's certificate is valid. What is wrong?
    Any certificate that authority has issued to anyone then authenticates as any client. `tls_client_auth` is valid chain **and** an exact match against the one registered subject value; dropping the second half turns client authentication into "holds a certificate from a popular issuer".
  • Why does RFC 8705 §2 require exactly one subject-identifier parameter in the registration?
    Because the comparison must be unambiguous. If two expected values were registered, a server would have to decide whether either suffices or both must match, and implementations would diverge. One parameter means one field of the presented certificate is checked against one registered string.
  • A client's certificate authenticates in testing and fails in production behind a load balancer. Where would you look?
    At whether the connection terminating TLS actually requests and forwards the client certificate, and at whether the request went to the ordinary token endpoint rather than the mutual-TLS one the server advertises in `mtls_endpoint_aliases`. A certificate never requested is a certificate never presented.

saying these in an interview costs you the question

  • Thinks the certificate replaces client_id in the token request
  • Believes a valid chain alone authenticates the client
  • Says self_signed_tls_client_auth still needs a certificate authority
  • Registers more than one tls_client_auth subject parameter
  • Confuses authenticating with a certificate with binding a token to one
  • Assumes any token endpoint will ask for a client certificate