Sender-constraining tokens close the bearer token theft gap

At a glance

What this is: This is an analysis of bearer tokens versus sender-constraining tokens, with the key finding that binding a token to a cryptographic key makes stolen tokens inert.

Why it matters: It matters because IAM, PAM, and NHI programmes all rely on controlling who or what can present credentials, and bearer semantics leave a reusable artifact wherever token leakage occurs.

👉 Read WorkOS' analysis of bearer tokens and sender-constraining tokens

Context

Bearer token governance is simple on paper and brittle in practice. If an attacker obtains the token, the resource server treats the attacker as the legitimate presenter until the token expires. For identity teams, that means leakage anywhere in the handling path can turn into direct access.

Sender-constraining changes the trust model for API access by requiring proof that the presenter controls the private key associated with the token. That is a material shift for NHI governance, because the control is no longer just token issuance and expiry, but binding and proof at request time.

Key questions

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. Use short lifetimes, strict storage controls, and sender-constraining for high-value or cross-boundary traffic. If a token can be replayed after leakage, the design is still too permissive for the risk level.

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. It is most valuable where a stolen token would otherwise be enough to impersonate the client and reach sensitive APIs.

Q: What breaks when token binding is absent from API authorisation?

A: The main failure is replay. If a token is copied from a log, browser store, or intercepted request, the attacker can present it exactly as the legitimate client would. Without sender-constraining, the resource server has no cryptographic way to distinguish the thief from the original holder.

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.

Technical breakdown

Bearer token replay risk in API authorisation

A bearer token is a possession credential. The authorisation server issues a token, the client presents it, and the resource server checks claims such as expiry, audience, and scope. It does not verify whether the presenter is the original recipient. That makes bearer tokens operationally easy, but any exposure in logs, browser storage, redirects, or intercepted traffic creates a usable credential until expiry. In governance terms, the token itself is the authority artifact, so theft equals immediate replay potential.

Practical implication: reduce bearer lifetime, harden token handling paths, and treat any leaked bearer token as a live access credential.

DPoP proof of possession and key thumbprints

DPoP adds a second layer of verification. The client generates a key pair, the authorisation server embeds a thumbprint of the public key into the access token, and each request includes a signed DPoP proof JWT. The resource server validates both artifacts and checks that the proof matches the bound key and the request context. Because the proof is short-lived and tied to the method and URI, replay is much harder even if the access token is copied.

Practical implication: if browser or mobile clients must carry sensitive tokens, DPoP is the most practical sender-constraining pattern to evaluate first.

mTLS-constrained tokens and transport-bound identity

mTLS binds the access token to a client certificate presented during the TLS handshake. The authorisation server records the certificate thumbprint in the token, and the resource server requires the same certificate at connection time. This is stronger at the transport layer than bearer semantics and fits machine clients with stable key material. The trade-off is operational complexity: PKI, certificate lifecycle management, and browser compatibility all become part of the control surface.

Practical implication: use mTLS where service identity is stable and PKI operations are already mature, especially for regulated or high-assurance APIs.

Threat narrative

Attacker objective: The attacker aims to use a stolen token as a valid access credential and reach protected APIs or data as the original subject.

1. Entry occurs when a bearer token is exposed through logs, browser memory, query parameters, or a compromised script, giving the attacker a usable credential.
2. Credential access is immediate because the token is a possession artifact, so the attacker can replay it without needing the original client or any private key.
3. Impact is account or API takeover for the token lifetime, with replay continuing until expiry unless additional revocation or binding controls exist.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Sender-constraining is the named control shift, but the real governance change is proof-bound access. A bearer model authorises the artefact, while DPoP and mTLS authorise the presenter through a cryptographic relationship. For NHI governance, that matters because the security property moves from storage discipline to runtime proof, which is a different control question entirely.

Token theft becomes a lifecycle issue as soon as access artefacts outlive the trusted context that issued them. Short lifetimes reduce exposure, but they do not change the fact that a leaked bearer token remains valid until it expires. The practitioner conclusion is that issuance, transport, and revocation must be governed as one lifecycle, not as separate tasks.

Bearer token exposure is a workload identity problem before it is an application bug. Logs, browser storage, and third-party scripts are all identity surfaces when tokens are reusable. That means IAM, PAM, and NHI teams should read token handling as a privilege design problem, not just an application security defect.

Proof of possession is becoming the default expectation for sensitive APIs. The article’s FAPI 2.0 reference is a sign that regulated access paths are moving away from bare possession and toward cryptographic binding. Practitioners should expect stronger sender-binding requirements to show up first in high-risk and regulated integration paths.

From our research:

• 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.
• For adjacent NHI governance patterns, see Guide to the Secret Sprawl Challenge for how exposed credentials keep creating blast radius after discovery.

What this signals

Proof-bound access is becoming the practical floor for sensitive API governance. As token theft remains useful wherever possession is enough, programme owners should expect stronger sender-binding to appear first in regulated, browser-facing, and partner-exchange flows. The decision is less about cryptography novelty and more about whether a stolen token should remain a live credential.

Token handling is now an identity lifecycle problem, not a transport-only issue. If issuance, proof binding, and expiry are managed separately, the programme will still leave replay paths open. Teams should align secret handling, API authorisation, and workload identity governance so that an exposed token is not treated as a routine incident with no architectural consequence.

Cryptographic binding matters most where NHI-style credentials outlive the channel that carried them. That includes service-to-service traffic, browser-mediated APIs, and regulated integrations where proof of possession is increasingly expected. For teams planning Zero Trust Architecture, this is where bearer semantics start to look like an assumption rather than a control.

For practitioners

• 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. Prioritise sender-constraining for any path where the presenter cannot be trusted to preserve possession-only credentials.
• 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. Validate that the resource server checks the proof, the token thumbprint, and the request binding together.
• 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. Keep the certificate thumbprint bound into the token and treat certificate rotation as part of identity governance.

Key takeaways

• Bearer tokens remain easy to deploy, but their security model collapses the moment a stolen token can be replayed by anyone who holds it.
• Sender-constraining shifts authorisation from possession to proof, which materially changes how API identity should be governed.
• Teams handling sensitive data should treat DPoP or mTLS as a control choice, not an optional enhancement, when token reuse would be unacceptable.

Key terms

• Bearer Token: A bearer token is an access credential that grants authority to whoever presents it. In practice, it is a possession-based artifact such as a JWT or opaque string, and if it leaks, the leak is immediately actionable until the token expires or is revoked.
• Sender-Constraining Token: A sender-constraining token is bound to a cryptographic key so the token alone is not enough to gain access. The presenter must prove possession of the matching private key at request time, which changes a leaked token from a usable credential into a near-useless artifact.
• DPoP: Demonstrating Proof of Possession is an application-layer sender-constraining method for OAuth 2.0. The client signs a short-lived proof for each request, and the resource server checks that proof against the key bound into the access token, reducing replay value if the token is stolen.
• mTLS-Constrained Token: An mTLS-constrained token is tied to a client certificate presented during the TLS handshake. That binding makes the certificate part of the access control decision, which is especially useful for machine clients that can manage PKI and need stronger transport-level assurance.

Deepen your knowledge

Bearer token replay risk and sender-constraining design are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your API estate still relies on possession-only credentials, this is a useful starting point.

This post draws on content published by WorkOS: Bearer tokens vs sender-constraining tokens. Read the original.