Notifications
Clear all
Topic starter
06/06/2026 1:33 am
TL;DR: Bearer tokens grant access to whoever presents them, which makes token theft, logging exposure, and replay viable until expiry; sender-constraining tokens bind the token to a cryptographic key so possession alone is not enough, according to WorkOS. The governance shift is clear: modern API access needs proof of possession, not just possession.
NHIMG editorial — based on content published by WorkOS: Bearer tokens vs sender-constraining tokens
Questions worth separating out
Q: How should security teams reduce the risk of bearer token theft in APIs?
A: Treat bearer tokens as reusable credentials and assume they will be exposed somewhere in the delivery path.
Q: When should organisations choose sender-constraining over bearer tokens?
A: Choose sender-constraining when tokens cross untrusted channels, when regulation demands proof of possession, or when token lifetimes must be long.
Q: What breaks when token binding is absent from API authorisation?
A: The main failure is replay.
Practitioner guidance
- Classify where bearer tokens cross trust boundaries Map every place a token can leave a controlled backend path, including browsers, mobile apps, logs, and third-party scripts.
- Adopt DPoP for public clients with sensitive scopes Use DPoP where the client can manage a private key but cannot be trusted to keep a bearer token isolated from inspection or replay.
- Reserve mTLS for stable machine-to-machine workloads Use mTLS when the workload can sustain certificate lifecycle management and you need stronger transport binding than application-layer proof alone.
What's in the full article
WorkOS' full article covers the implementation detail this post intentionally leaves for the source:
- Step-by-step DPoP request construction, including key generation, thumbprints, and proof validation logic.
- Operational comparison of bearer, DPoP, and mTLS patterns for browser, mobile, and backend clients.
- Library-level implementation notes across Python, Node.js, and Java tooling.
- How FAPI 2.0 and regulated API requirements affect sender-constraining decisions.
👉 Read WorkOS' analysis of bearer tokens and sender-constraining tokens →
Bearer tokens vs sender-constraining tokens: are your controls enough?
Explore further
06/06/2026 2:44 am
Bearing a token was designed for simple presentation, not adversarial replay. That assumption fails when the token crosses environments where exposure is realistic, because possession becomes equivalent to authority. The implication is that identity programmes cannot treat token leakage as a downstream incident only, since the token design itself determines whether leakage is catastrophic.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: What is the difference between DPoP and mTLS for token binding?
A: DPoP binds the token at the application layer with a signed proof on each request, while mTLS binds it at the transport layer using the client certificate in the TLS handshake. DPoP is easier to adopt in browser and mobile contexts, while mTLS is stronger but operationally heavier.
👉 Read our full editorial: Sender-constraining tokens close the bearer token theft gap
