Skip to main content
Version: v2.0 (latest)

Sender-Constrained Tokens (DPoP and mTLS)

By default, access tokens are bearer tokens. For higher security, bind a token to its rightful holder so that a leaked token is useless to anyone else.

  • DPoP (RFC 9449). Demonstrating Proof of Possession (DPoP) binds the token to a key you hold. Generate a key pair for the session. Send a fresh DPoP proof JWT in the DPoP header on the token request and on every subsequent call, such as userinfo. The proof is signed by your session key and bound to the HTTP method and URL. The issued token is bound to your key's thumbprint.
  • mTLS-bound tokens (RFC 8705). When you authenticate with mutual TLS (mTLS, tls_client_auth), the access token is bound to your client certificate. Present the same certificate on subsequent calls.

Calling Userinfo With a DPoP-Bound Token​

curl -s "$BASE/oidc/v1/userinfo" \
  -H "Authorization: DPoP <access_token>" \
  -H "DPoP: <dpop_proof_jwt>"

Use a library that implements DPoP — constructing and rotating proofs by hand is error-prone.