0Pricing
OAuth2 & OpenID Connect Deep Dive · Lesson

Sender-Constrained Tokens with mTLS

Learn how mutual-TLS client certificate binding turns bearer tokens into sender-constrained tokens, stopping stolen tokens from being replayed by attackers.

Sender-Constrained Tokens with mTLS is a free OAuth2 & OpenID Connect Deep Dive lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the OAuth2 & OpenID Connect Deep Dive learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

The Bearer Token Weakness

A plain bearer token works for anyone who holds it. If it leaks via logs, a proxy, or an XSS bug, the thief can use it freely. Sender-constrained tokens fix this by binding the token to the legitimate client.

What Is mTLS?

Mutual TLS means both sides present certificates: the server proves its identity (as usual) and the client also presents a certificate. The authorization server can then bind issued tokens to that client certificate.

RFC 8705

This is standardized in RFC 8705 (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens). It covers both client authentication via mTLS and certificate binding of access tokens.

The cnf Claim

When the AS issues a certificate-bound token, it records a confirmation (cnf) claim containing the SHA-256 thumbprint of the client certificate under the key x5t#S256.

{
  "sub": "client-app",
  "cnf": {
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
  }
}

Resource Server Check

When the client calls an API over mTLS, the resource server computes the thumbprint of the presented certificate and compares it to the token's cnf.x5t#S256. If they differ, the token is rejected.

thumb = sha256(der_of_client_cert)
if base64url(thumb) != token.cnf['x5t#S256']:
    reject('certificate binding mismatch')

Why a Stolen Token Is Useless

Even with the token, an attacker cannot present the client's private key, so they cannot complete the mTLS handshake with the matching certificate. The thumbprint will not match, and the API rejects them.

mTLS Client Authentication

RFC 8705 also lets clients authenticate at the token endpoint with their certificate instead of a shared secret, using methods tls_client_auth (PKI) or self_signed_tls_client_auth.

mTLS Endpoint Aliases

Because mTLS needs a separate TLS configuration, providers publish mtls_endpoint_aliases in discovery so clients hit the certificate-bound versions of the token and other endpoints.

{
  "mtls_endpoint_aliases": {
    "token_endpoint": "https://mtls.op.example.com/token"
  }
}

mTLS vs DPoP

Both achieve sender-constraint:

  • mTLS — relies on TLS-layer certificates, great for server-to-server and infrastructure with PKI.
  • DPoP — application-layer proof JWTs, better for browser/public clients that cannot manage client certs.

Operational Considerations

mTLS requires certificate provisioning, rotation, and a TLS terminator that forwards the client cert to your app. Plan for cert lifecycle and ensure your reverse proxy passes the verified certificate to the resource server.

When to Adopt It

Choose mTLS-bound tokens for high-assurance, regulated, or financial-grade APIs and trusted backend services where certificate management is feasible. It dramatically raises the cost of token theft.

Quick Check

Test your mTLS binding knowledge.

Recap

mTLS sender-constrained tokens (RFC 8705) bind a token to the client's certificate.

  • The token carries a cnf.x5t#S256 certificate thumbprint.
  • Resource servers match the presented cert's thumbprint; a stolen token without the private key fails.
  • mTLS also enables certificate-based client authentication and uses mtls endpoint aliases.
  • Compare with DPoP for public clients.

Frequently asked questions

Is the “Sender-Constrained Tokens with mTLS” lesson free?

Yes — the full text of “Sender-Constrained Tokens with mTLS” is free to read here on the web, and the OAuth2 & OpenID Connect Deep Dive course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the OAuth2 & OpenID Connect Deep Dive course, upgrade to CoddyKit PRO.

What will I learn in “Sender-Constrained Tokens with mTLS”?

Learn how mutual-TLS client certificate binding turns bearer tokens into sender-constrained tokens, stopping stolen tokens from being replayed by attackers. You practise OAuth2 & OpenID Connect Deep Dive with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start OAuth2 & OpenID Connect Deep Dive?

No prior experience is required. OAuth2 & OpenID Connect Deep Dive on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Sender-Constrained Tokens with mTLS” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this OAuth2 & OpenID Connect Deep Dive lesson?

Yes. Every OAuth2 & OpenID Connect Deep Dive lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Consent & User Experience
  2. Cross-Origin Resource Sharing (CORS)
  3. Front-Channel vs. Back-Channel Logout
  4. Sender-Constrained Tokens with mTLS
← Back to OAuth2 & OpenID Connect Deep Dive