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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: Binding a token to a cryptographic key removes the replay value of a stolen token.
Why it matters: IAM teams, API owners, and NHI practitioners need this distinction because token theft turns into direct access when possession is enough, and sender-constraining changes the trust model for machine and application credentials.
Context
Bearer tokens are simple to implement because the resource server only checks whether the presented token is valid, not whether the presenter is the same party that received it. That design makes bearer tokens efficient across applications, but it also means any exposed token can be replayed until expiry.
Sender-constraining changes the authorization model by requiring a proof tied to a private key at request time. For identity programmes that govern APIs, service accounts, and other NHI access paths, the question is no longer whether a token exists, but whether the presenter can prove possession of the bound key.
The article frames this as a practical shift for regulated and cross-boundary access. When tokens move through browsers, mobile apps, or machine clients with exposure risk, the governance problem is not token issuance alone but the trust assumption that possession equals legitimacy.
Key questions
Q: What breaks when bearer tokens are stolen or logged?
A: Bearer tokens become immediately reusable because possession is enough to authorize the request. If the token is exposed in logs, browser storage, or interception, an attacker can replay it until expiry and act as the original caller. That is why bearer semantics create replay risk even when the rest of the system is correctly configured.
Q: Why do sender-constraining tokens reduce replay risk?
A: They require the requester to prove control of a private key that matches the token binding. A stolen token without the key is not enough, so the attacker cannot simply present the string and gain access. The control shifts from token possession to request-time cryptographic proof.
Q: When should teams use DPoP instead of bearer tokens?
A: Use DPoP when the token crosses trust boundaries, the client can handle request signing, and replay would create meaningful business or security impact. It is especially appropriate for browser and mobile clients that need stronger binding without a full TLS certificate model.
Q: How should teams decide between DPoP and mTLS?
A: Choose DPoP when you need sender-constraining with lower deployment friction and broader client compatibility. Choose mTLS when the environment can support certificate lifecycle management and you need stronger transport-layer binding, such as in regulated or high-assurance API deployments.
Technical breakdown
Bearer tokens: why possession becomes authorization
Bearer tokens are stateless authorization credentials. The authorization server issues a token, and the resource server accepts it if claims such as expiry, audience, and scope check out. No cryptographic proof from the presenter is required, so any party that obtains the token can replay it until the token expires. That simplicity is why bearer tokens are widely supported, but it also means logging exposure, browser storage exposure, and network interception all become direct access paths. The security model is therefore built on the assumption that token confidentiality holds from issuance to use.
Practical implication: treat bearer tokens as replayable credentials and limit their lifetime and exposure surfaces aggressively.
Sender-constraining tokens and proof of possession
Sender-constraining tokens bind the access token to a cryptographic key, usually by storing a public key thumbprint in the token. The client must then prove it holds the matching private key when it makes each request. DPoP does this at the application layer with signed request proofs, while mTLS does it at the transport layer with client certificates. In both cases, the resource server validates both token integrity and presenter proof, which means possession of the token alone is no longer sufficient. The result is a credential that is only usable by the entity that can demonstrate key control.
Practical implication: adopt proof-of-possession patterns where token replay would create unacceptable blast radius.
DPoP versus mTLS-constrained tokens
DPoP and mTLS solve the same problem with different operational trade-offs. DPoP works over HTTPS without changing the TLS stack and is better suited to public clients such as browser and mobile applications. mTLS provides stronger channel binding but depends on PKI, certificate handling, and client certificate distribution. The article also notes that mTLS-constrained tokens are common in high-assurance environments such as financial services and open banking. From an architecture perspective, the choice is not about which is universally better, but about where the deployment context can support cryptographic binding without creating new operational fragility.
Practical implication: match the sender-constraining method to the client type, trust boundary, and certificate or key management model.
Threat narrative
Attacker objective: Use a stolen access token to gain unauthorized API or account access before expiry.
- Entry occurs when a bearer token is exposed through logging, browser storage, query strings, or interception, allowing an attacker to capture a usable credential without compromising the original client.
- Credential access follows immediately because the token itself is the authorisation artifact, so the attacker can present it directly to the resource server as long as it remains valid.
- Impact is account or API access for the token lifetime, unless the system requires proof of possession and rejects requests that cannot demonstrate the bound key.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Fake Dependabot commits 2023: Stolen GitHub tokens were used to push fake Dependabot commits to hundreds of repos, adding workflows that stole Actions secrets.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Bearer tokens are a replay problem, not just an authentication convenience: the model assumes the holder of the string is the legitimate caller. That assumption works only while token confidentiality is perfect, which is not a realistic governance premise in browser, logging, and multi-tenant environments. The practical conclusion is that token design must be assessed as a control boundary, not just an implementation detail.
Proof of possession is the real control shift: sender-constraining changes access from 'can present the token' to 'can present the token and prove key control'. That difference matters because stolen credentials cease to be immediately reusable, which changes both attacker economics and incident response assumptions. For identity programmes, the decision point is whether replay resistance belongs in the architecture for that access path.
Ephemeral token discipline still does not close the trust gap: short lifetimes reduce exposure, but they do not remove the core assumption that possession equals authorization. When tokens cross trust boundaries, the governance model should treat key binding as the control that converts a leaked token from a usable credential into an inert artifact. Practitioners should re-evaluate where bearer semantics are still acceptable.
Sender-constraining belongs in NHI governance, not only API design: service accounts, backend clients, and application tokens are all machine identities with distinct exposure risks. The article shows that access control for these identities now depends on whether the identity can prove it is the legitimate presenter at request time. That is a governance question about NHI trust, not just a protocol choice.
Named concept: proof-of-possession access: the article's core contribution is the shift from possession-based authorization to request-time cryptographic proof. This pattern is increasingly the right mental model for sensitive APIs, regulated environments, and any identity path where token replay would create unacceptable blast radius. Practitioners should use it to separate acceptable convenience from control failure.
What this signals
Proof-of-possession access: the important governance shift is not token format but the control assumption behind it. Bearer semantics assume that confidential storage is enough, while sender-constraining assumes the presenter must prove legitimacy at request time. That makes replay resistance an architectural requirement, not a hardening option.
Teams that still rely on bearer tokens should separate low-risk internal service calls from cross-boundary or regulated API flows. The latter have a materially different trust profile because token leakage, log exposure, or browser compromise turns into immediate access unless the token is bound to a key.
For practitioners
- Map bearer-token exposure paths Inventory where access tokens can leak through logs, browser storage, query strings, and third-party scripts, then classify which APIs can tolerate replay risk and which cannot.
- Require proof of possession for sensitive APIs Use sender-constraining for access paths that cross trust boundaries or carry regulated data, so token replay alone does not grant access.
- Choose DPoP for public clients Prefer DPoP when browser or mobile clients need sender-constrained access without changing the TLS stack, and reserve mTLS for environments that can sustain certificate operations.
- Limit bearer-token blast radius Keep bearer tokens short-lived where proof of possession is not yet feasible, and pair that with strict storage and logging controls until the architecture can change.
Key takeaways
- Bearer-token designs keep authorization tied to possession, which means any leaked token can be reused until expiry unless other controls intervene.
- Sender-constraining changes the trust model by requiring cryptographic proof from the presenter, so stolen tokens no longer carry the same replay value.
- For sensitive APIs and regulated access paths, the governance question is whether proof of possession belongs in the architecture now or remains a future control gap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Bearer tokens rely on possession alone, which is the core weakness this article addresses. |
| NHI-02 — Secret Leakage | The article highlights logging, browser storage, and interception as token leakage paths. | |
| Recommendation — Replace possession-only bearer semantics with sender-constrained authentication for sensitive access paths. Reduce token leakage by removing bearer tokens from logs, browser storage, and query parameters. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token lifetime, rotation, and revocation are central to mitigating bearer-token exposure. |
| Recommendation — Apply authenticator management controls to shorten lifetimes and revoke exposed access tokens quickly. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The article centers on how stolen tokens become reusable credentials for adversaries. |
| Recommendation — Map token theft paths to credential-access detection and prioritize replayable credentials for monitoring. | ||
| NIST Zero Trust (SP 800-207) | 8.3 — Flow Policy Enforcement Point | Sender-constraining reinforces zero-trust decisions at request time instead of trusting token possession alone. |
| Recommendation — Enforce request-time verification so access decisions do not rely on token possession alone. | ||
Key terms
- Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
- 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.
- Proof-of-Possession: Proof-of-possession binds a token or credential to a specific key so possession of the token alone is not enough to use it. For AI agents, it reduces replay risk and helps ensure that an intercepted credential cannot be reused by a different actor.
- DPoP: Demonstrating Proof of Possession is an HTTP-layer method that attaches a signed proof to each request. The proof ties the token to a client-held key and to the specific request details, which makes replay harder even when TLS terminates at gateways or proxies. It suits browsers and mobile clients better than transport-bound methods.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 5, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org