TL;DR: Sender-constrained tokens bind OAuth access to the caller’s private key, so stolen bearer tokens cannot be replayed without the matching key, according to Scramble ID. The practical shift is operational, not theoretical: short TTLs still matter, but proof-of-possession makes token theft and proxy leakage far less useful.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Scramble ID's blog post: Sender-constrained OAuth tokens use mTLS or DPoP to bind token use to a specific key, reducing replay risk for NHIs.
Why it matters: It matters because IAM teams still need to govern token leakage, proxy trust, and key lifecycle even when bearer replay is removed from the equation.
Context
OAuth bearer tokens are reusable by design, which means any copy found in logs, memory, proxies, or traces can be replayed until expiry. Sender-constrained tokens change that trust model by requiring the caller to prove possession of the corresponding private key at use time.
For NHI programmes, that shifts control from token secrecy alone to token binding, validation, and key governance. The article frames mTLS and DPoP as two proof-of-possession patterns with different operational fit, not as interchangeable branding around the same control.
The main governance gap is not whether a token exists, but whether the resource server can reliably verify who or what is presenting it. Without that check, OAuth access for service accounts and workload identities remains vulnerable to replay even when credentials are short-lived.
Key questions
Q: What breaks when OAuth bearer tokens are replayed instead of stolen credentials?
A: Bearer-token replay breaks the assumption that MFA and SSO protect the full access lifecycle. Once a valid token is copied, the attacker can use it without another login, because the resource server treats possession of the token as sufficient proof. That is why the control boundary has to extend beyond sign-in and into token issuance, storage, binding, and revocation.
Q: Why do sender-constrained tokens reduce risk for service accounts and workloads?
A: They force the caller to prove it holds the private key that was bound to the token at issuance. That stops simple token copying from becoming direct access, which is especially important for service accounts, API clients, and other NHIs that move through many trust boundaries.
Q: How do teams know whether mTLS or DPoP is being validated correctly?
A: Check whether the resource server is enforcing the binding, not just whether tokens are being issued. For mTLS, the certificate or thumbprint must survive every proxy hop. For DPoP, the verifier must reject duplicate jti values, mismatched methods, and stale proofs.
Q: When should organisations choose mTLS over DPoP for access tokens?
A: Choose mTLS when you control both ends of the connection, can enforce end-to-end TLS, and already manage certificates at scale. Choose DPoP when TLS terminates at gateways, when browser clients are involved, or when the architecture needs application-layer proof that survives intermediaries.
Technical breakdown
Bearer replay risk in OAuth for non-human identities
Bearer tokens are valid because they are presented, not because the caller proves possession of a separate secret at request time. That makes them efficient, but also reusable if intercepted. In NHI environments, this matters because API keys, workload tokens, and delegated access often move through gateways, logs, and automation layers where accidental disclosure is common. Sender-constrained tokens add a confirmation claim such as cnf.jkt so the resource server can verify that the token is being used by the same key that was bound at issuance.
Practical implication: Treat token replay as a binding problem, not just an expiry problem, and check where your resource servers actually enforce caller proof.
mTLS sender-constrained tokens and gateway trust
mTLS binds the token to the client certificate presented during the TLS session, which works well when the organisation controls the network path end to end. The operational failure mode is usually not cryptography but architecture: TLS termination, proxy rewriting, or inconsistent certificate rotation can break the binding before the resource server sees it. If the validated certificate thumbprint does not survive the path, the sender constraint collapses into ordinary bearer behaviour. That makes certificate propagation and verification part of the identity control plane, not just transport security.
Practical implication: Verify that client certificate evidence reaches the resource server unchanged after every proxy, gateway, or mesh hop.
DPoP proof-of-possession and request-level binding
DPoP shifts proof to the application layer by having the client sign a proof JWT for each request. The proof includes the HTTP method, URL, issued-at time, unique identifier, and often an access-token hash, so replay detection can happen at request granularity. The important operational detail is that the verifier must normalise URLs, enforce jti uniqueness, and tolerate only a tight iat window. DPoP is especially relevant when clients can hold keys but not certificates, such as mobile or desktop applications and multi-tenant APIs.
Practical implication: Use DPoP where mTLS is impractical, but enforce proof freshness, replay cache checks, and strict request canonicalisation.
Threat narrative
Attacker objective: Reuse stolen OAuth access to impersonate a workload or service account and reach protected APIs without possessing the legitimate caller key.
- Entry occurs when a bearer token is stolen from logs, proxies, memory, or another interception point and copied for reuse.
- Escalation happens when the attacker presents that token to the resource server without needing the original caller’s private key.
- Impact is the ability to reuse the stolen access until expiry unless the resource server enforces sender constraints and rejects the replay.
Breaches seen in the wild
- Gainsight Salesforce breach 2025: Stolen OAuth tokens for Gainsight's Salesforce app, some eight years old, were used against customer orgs; Google saw 200+ instances at risk.
- GitHub OAuth token breach 2022: Stolen Heroku and Travis CI OAuth tokens let an attacker clone private repos from dozens of orgs, including npm, and reuse an AWS key found in them.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Sender-constrained tokens turn OAuth replay from an access problem into a proof problem: the token alone is no longer sufficient to authenticate a non-human caller. That matters because bearer semantics assume the token is the authority, while sender constraints require the caller to prove it still holds the right key. The implication for practitioners is that replay resistance now depends on validation at the resource server boundary, not on token obscurity.
Token binding assumes the binding evidence survives the full request path: mTLS only works when the validated client certificate or thumbprint reaches the resource server intact, and DPoP only works when the verifier canonicalises the request exactly as the client signed it. Proxies, gateways, and retry libraries become part of the identity control plane. The implication is that transport, application, and IAM teams can no longer treat these as separate layers.
Short-lived tokens do not remove replay risk, they only compress it: sender constraint reduces the usefulness of a stolen token, but it does not eliminate the need for rotation, revocation propagation, and high-signal monitoring. Proof-of-possession failures are operational evidence, not just noise, because they can indicate token theft, misbinding, or gateway defects. The implication is that NHI governance has to treat PoP validation telemetry as a first-class control signal.
Identity blast radius becomes the decisive concept for sender-constrained NHI design: a shared DPoP key or broken mTLS propagation can expand compromise across every downstream service that trusts the same caller identity. That is a governance failure, not a cryptographic nuance. The implication is that teams should measure how far one key or certificate can travel before it becomes a systemic access path.
What this signals
Sender binding changes where the control lives: once tokens are tied to a private key, the resource server becomes the enforcement point that decides whether the caller is legitimate. That means gateway behaviour, certificate propagation, and proof validation are part of identity governance, not separate plumbing.
Identity blast radius is the right design question: a shared DPoP key or certificate can turn one compromise into many downstream API exposures. In practice, workload-scoped keys are more defensible than organisation-scoped trust objects because they keep failure contained to a smaller access domain.
For practitioners
- Enforce sender constraint at the resource server Require every sensitive OAuth-protected API to verify cnf-bound proof, certificate thumbprint, or DPoP validation before honouring the token.
- Preserve client identity through gateways Audit reverse proxies, meshes, and API gateways to confirm that client certificate evidence or DPoP request data is not stripped or rewritten.
- Separate keys by workload identity Mint distinct DPoP keys or client certificates per workload so one compromise does not create a shared access path across services.
- Treat PoP failures as security events Alert on cnf.jkt mismatches, duplicate jti values, unexpected audience changes, and spikes in proof rejection, then investigate for replay or misconfiguration.
- Keep token lifetimes short anyway Use proof-of-possession with short access-token TTLs so replay windows are reduced even when sender binding is working as intended.
Key takeaways
- Bearer token replay is still the core risk for NHIs when OAuth credentials are intercepted in transit or at rest.
- Sender-constrained tokens reduce that risk by requiring proof of possession, but only if the resource server sees and validates the proof correctly.
- The limiting factor is operational enforcement, especially proxy handling, key lifecycle, and replay detection.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Sender-constrained tokens address OAuth authentication that relies on bearer replay. |
| NHI-07 — Long-Lived Secrets | The article stresses that short TTLs still matter alongside proof-of-possession. | |
| NHI-05 — Overprivileged NHI | A replayable token can expose far more than intended if scope is too broad. | |
| Recommendation — Bind NHI tokens to caller proof so intercepted credentials cannot be reused without the matching key. Keep NHI token lifetimes short and pair them with sender constraints to narrow replay exposure. Limit token scope so replayed credentials cannot reach unrelated APIs or downstream services. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token and key lifecycle handling map directly to authenticator management. |
| Recommendation — Manage NHI token and key lifecycles so rotation, revocation, and binding are enforced consistently. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post is fundamentally about enforcing who or what may use an access token. |
| Recommendation — Apply entitlement checks so only the bound caller can exercise the granted access. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Stolen OAuth tokens are the credential-access step that sender constraints are meant to blunt. |
| Recommendation — Hunt for token theft paths and map replay risk to credential-access detection and containment. | ||
Key terms
- Sender-constrained token: A sender-constrained token is tied to a specific client or cryptographic proof, rather than being usable by anyone who steals it. This reduces replay risk and is especially important where tokens can reach automation, services, or agents with broad API access.
- 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.
- mTLS sender constraint: A token-binding approach that ties OAuth use to a mutual TLS client certificate. The resource server must see the validated certificate or thumbprint after proxies and gateways, otherwise the caller can fall back to bearer-style replay.
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 22, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org