0Pricing
OAuth2 & OpenID Connect Deep Dive · Lekcja

Tokeny powiązane z nadawcą za pomocą mTLS

Dowiedz się, jak powiązanie z certyfikatem klienta mutual TLS zmienia tokeny bearer w tokeny powiązane z nadawcą, uniemożliwiając atakującym ponowne użycie skradzionych tokenów.

Tokeny powiązane z nadawcą za pomocą mTLS to bezpłatna lekcja OAuth2 & OpenID Connect Deep Dive na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej OAuth2 & OpenID Connect Deep Dive, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs OAuth2 & OpenID Connect Deep Dive zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

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.

Często zadawane pytania

Czy lekcja „Tokeny powiązane z nadawcą za pomocą mTLS” jest bezpłatna?

Tak — pełny tekst „Tokeny powiązane z nadawcą za pomocą mTLS” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu OAuth2 & OpenID Connect Deep Dive, przejdź na CoddyKit PRO. Kurs OAuth2 & OpenID Connect Deep Dive zawiera 4 lekcji w sumie.

Co nauczysz się w „Tokeny powiązane z nadawcą za pomocą mTLS”?

Dowiedz się, jak powiązanie z certyfikatem klienta mutual TLS zmienia tokeny bearer w tokeny powiązane z nadawcą, uniemożliwiając atakującym ponowne użycie skradzionych tokenów. Ćwiczysz OAuth2 & OpenID Connect Deep Dive z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć OAuth2 & OpenID Connect Deep Dive?

Nie wymagamy żadnego doświadczenia. OAuth2 & OpenID Connect Deep Dive w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Tokeny powiązane z nadawcą za pomocą mTLS”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji OAuth2 & OpenID Connect Deep Dive?

Tak. Każda lekcja OAuth2 & OpenID Connect Deep Dive zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Zgoda i doświadczenie użytkownika
  2. Udostępnianie zasobów między domenami (CORS)
  3. Wylogowanie front-channel a back-channel
  4. Tokeny powiązane z nadawcą za pomocą mTLS
← Powrót do OAuth2 & OpenID Connect Deep Dive