mTLS & Sender-Constrained Tokens (DPoP)

Bearer tokens work for anyone who holds them. Sender-constrained tokens are bound to a key the client proves possession of:

• mTLS (RFC 8705): client certificate authenticates the client and access tokens are bound to the cert thumbprint (cnf.x5t#S256). Common for B2B and in service meshes (SPIFFE identities).
• DPoP (RFC 9449): the client signs a per-request proof JWT (method, URL, time, token hash) with its private key; tokens carry cnf.jkt. Works at the application layer, including browsers and mobile. Financial-grade profiles (FAPI 2.0) require one of them.

Token binding options

GET /v1/accounts HTTP/1.1
Host: api.bank.example
Authorization: DPoP eyJhbGciOiJFUzI1NiIs…            # access token with cnf.jkt
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7…}
# DPoP proof claims: {"htm":"GET","htu":"https://api.bank.example/v1/accounts","iat":1760170000,"jti":"…","ath":"<sha256 of access token>"}

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata: { name: default, namespace: payments }
spec:
  mtls: { mode: STRICT }      # all service-to-service traffic must present mesh certs

Common pitfalls

• mTLS terminated at a load balancer and identity not forwarded securely.
• Accepting DPoP proofs without checking htm/htu/iat/jti.
• Assuming mesh mTLS replaces application authorization.

Key points

• Bind tokens to keys for high-value APIs
• mTLS for services and B2B
• DPoP for apps at the HTTP layer

Further reading: RFC 9449: OAuth 2.0 DPoP