Skip to content
Agent Identity

IETF · February 2020

OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

RFC 8705

B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt

RFCStableAuthenticationFoundationField guide

Workload-style agents (SPIFFE/WIMSE) often already have a client cert. Binding the OAuth token to that cert is how you stop a stolen JWT from being replayed outside the workload.

At a glance

Problem
Bind client authentication and access tokens to a client certificate used in mutual TLS, so stolen tokens cannot be replayed from another TLS stack.
Identity / authn / authz
Authentication of the client (and of the token presenter). Certificate subject is not the user.

Actors

  • Client
  • Authorization server
  • Resource server

01

The gap for agents

RFC 8705 binds client authentication and access tokens to a client certificate used in mutual TLS, so stolen tokens cannot be replayed from another TLS stack. Workload-style agents that already have SPIFFE X.509-SVIDs should use this rather than inventing a JWT-only story.

Painful for browsers and many serverless agent hosts — that is why DPoP exists. FAPI 2.0 allows mTLS or DPoP.

02

Actors and trust boundaries

The TLS terminator that sees the client cert must be the RS (or a trusted ingress that forwards the cert in a header you actually trust). A CDN that strips mTLS makes cnf.x5t#S256 theatre. The certificate subject is not the user.

03

Mechanics

Client presents a certificate during TLS to the AS. AS issues an access token with cnf.x5t#S256 (SHA-256 thumbprint of the cert). RS requires the same certificate on the API call. Also defines mTLS client authentication (PKI or self-signed) at the token endpoint, with metadata use_mtls_endpoint_aliases.

cnf.x5t#S256from spec
Quoted RFC 8705: certificate thumbprint confirmation claim.

04

Step-by-step flows

Flow 1

Certificate-bound access token

  1. 1

    Client opens TLS to the AS token endpoint with its cert (SPIFFE SVID or otherwise).

  2. 2

    AS authenticates the client and issues an access token bound to the cert thumbprint.

  3. 3

    Client calls the RS on mTLS with the same cert and Authorization: Bearer (the token is still a bearer header, but useless without the cert).

  4. 4

    RS checks TLS cert thumbprint equals cnf.

05

Identity vs authentication vs authorization

Authentication of the client and of the token presenter. Authorization remains the token. User identity remains OIDC/sub.

06

How it composes

  • SPIFFE / SPIRE

    X.509-SVID is the cert. Pair with SPIFFE OAuth client auth.

  • DPoP

    App-layer alternative when you cannot pass client certs.

  • FAPI 2.0

    One of two allowed sender-constraint methods.

  • WIMSE credentials

    WIC is an X.509 workload credential; mTLS is the transport-layer presentation WIMSE expects for certificates.

07

What bites agent implementers

  • Terminated TLS

    If ingress terminates TLS and the app never sees the client cert, binding is fiction unless you have a trusted header from that ingress.

  • User vs cert

    Do not stuff Alice into the certificate DN. Keep user in the token; keep workload in the cert.

08

Stability — what you can ship

RFC 8705, February 2020. Stable. https://www.rfc-editor.org/rfc/rfc8705.html

Catalog claims (short form)

cnf.x5t#S256
Certificate thumbprint confirmation claim.

Implementer notes

Excellent inside a mesh or when SPIFFE X.509-SVIDs are already the client cert. Painful for browsers and many serverless agent hosts. FAPI 2.0 allows mTLS or DPoP for sender constraint.

Relationship to others

Primary sources

  • RFC 8705https://www.rfc-editor.org/rfc/rfc8705.html