Sender-constrained tokens reduce OAuth replay risk for NHIs

At a glance

What this is: This is an analysis of sender-constrained OAuth tokens using mTLS and DPoP, with the key finding that binding tokens to a private key blocks bearer-token replay.

Why it matters: It matters because service accounts, workload identities, and API clients still fail when tokens are treated as reusable secrets instead of cryptographically bound credentials.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Scramble ID's analysis of sender-constrained tokens for OAuth replay prevention

Context

OAuth bearer tokens are convenient because any holder can use them, but that convenience creates replay risk the moment a token is copied from logs, proxies, or memory. Sender-constrained tokens change the trust model by requiring proof that the caller possesses a matching private key at the time of use.

For IAM and NHI programmes, this is a governance issue as much as a protocol choice. Service accounts, machine identities, and API clients are often treated as if token possession equals legitimacy, but proof-of-possession forces teams to separate token theft from token usability.

The article is mainly about how mTLS and DPoP close the bearer-token gap without requiring a complete redesign of OAuth. That is a typical problem pattern in modern machine identity estates, especially where credentials move across gateways, meshes, and external APIs.

Key questions

Q: How should security teams implement sender-constrained tokens for machine identities?

A: Start by matching the proof method to the deployment path. Use mTLS where you control the network and certificate chain end to end, and use DPoP where clients are diverse or cert plumbing is impractical. In both cases, keep TTLs short, validate the binding at the resource server, and monitor proof failures as potential abuse.

Q: Why do bearer tokens create more replay risk than proof-of-possession tokens?

A: Bearer tokens can be used by anyone who obtains them, so logs, proxies, memory dumps, or leaked traces can become active access. Proof-of-possession removes that portability by requiring the caller to prove control of a private key. That turns token theft into a much less useful event for attackers.

Q: What breaks when DPoP proof validation is inconsistent across clients and gateways?

A: Requests fail unpredictably when URL normalisation, HTTP method matching, clock skew, or replay checks differ between components. The result is not just false negatives, but pressure to weaken validation so flows keep working. Consistency matters because DPoP only works when every verifier applies the same binding rules.

Q: Who is accountable when a stolen token is replayed despite sender constraints?

A: Accountability usually sits with the team that owns token issuance, gateway enforcement, and key lifecycle, because proof-of-possession depends on all three. If certificates or DPoP keys are not rotated, validated, and revoked consistently, the control fails as a programme issue rather than a single technical defect.

Technical breakdown

How mTLS binds an access token to a client certificate

mTLS sender-constrained tokens use mutual TLS to prove that the caller owns the private key associated with a client certificate. The resource server validates the certificate or thumbprint after any proxy or gateway hop, then checks the OAuth cnf claim, often a JWK thumbprint, to confirm the token belongs to that identity. If TLS termination strips client-certificate context, the binding breaks and the token falls back toward bearer-style risk. The operational challenge is not the cryptography itself, but preserving trustworthy identity information across intermediaries.

Practical implication: verify that the resource server sees validated client-cert context after every proxy and gateway.

How DPoP prevents replay in public APIs

DPoP shifts proof-of-possession into the application layer, which makes it better suited to mobile, desktop, and diverse client environments. Each request carries a signed proof JWT containing the method, URL, issued-at time, and a unique identifier, while the access token is bound to the same key thumbprint through cnf.jkt. The server must validate the request binding, the time window, and replay uniqueness. If normalization is inconsistent or clocks drift too far, valid proofs fail even when the token is genuine.

Practical implication: normalise URLs, enforce jti replay detection, and keep the accepted time window tight.

Why key rotation and overlap windows matter for PoP

Sender-constrained tokens do not remove lifecycle risk from keys. During rotation, old and new keys may need an overlap window so in-flight requests can complete without breaking legitimate flows, but that overlap must be bounded and explicit. The verifier should accept both keys only for the defined transition period, then revoke the old key and propagate the change quickly. Without that discipline, PoP becomes brittle in production and operators either disable it or extend trust too far.

Practical implication: define overlap windows, revocation propagation steps, and emergency rollback paths before rollout.

Threat narrative

Attacker objective: The attacker wants to reuse a stolen OAuth token to impersonate the original caller and reach protected APIs without possessing the underlying key material.

1. entry via token theft from logs, proxies, memory dumps, or other exposed surfaces where a bearer token is copied without the caller's private key.
2. credential access is blocked by proof-of-possession, because the stolen token cannot be replayed unless the attacker also has the matching mTLS certificate or DPoP key.
3. impact is reduced blast radius and replay resistance, since the stolen token becomes unusable outside the authorised caller context.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

Bearer-token replay is a standing privilege problem, not just an authentication flaw. When a token can be copied and reused, the identity boundary is reduced to possession of a string rather than control of a caller. That is why proof-of-possession belongs in the same governance conversation as rotation, offboarding, and secret exposure. For NHI programmes, the implication is that token format directly shapes blast radius.

Sender-constrained tokens expose the identity blast radius as a controllable variable. mTLS and DPoP do not eliminate compromise, but they sharply limit what a stolen token can do outside its original context. That matters in environments where service accounts, gateways, and external APIs all handle credentials differently. Practitioners should treat token binding as a boundary control, not a niche protocol option.

Key lifecycle is the real control plane behind proof-of-possession. The article makes clear that overlap windows, revocation propagation, and request handling during rotation determine whether PoP survives production use. This is a lifecycle governance problem as much as an authentication one, and it maps directly to OWASP-NHI and Zero Trust expectations. The practitioner conclusion is simple: lifecycle discipline decides whether PoP remains enforceable.

mTLS and DPoP split the trust model by deployment reality, not by security philosophy. mTLS fits controlled internal paths where cert infrastructure already exists, while DPoP fits diverse clients and edge APIs where cert chains are impractical. The field-level lesson is that machine identity design must follow architecture boundaries. Teams should choose the proof model that matches the caller’s operating context, then enforce it consistently.

Proof failures are high-signal events because they often indicate real credential abuse. A cnf.jkt mismatch, DPoP replay, or invalid proof can signal theft, proxy rewriting, or misconfiguration, but all three deserve immediate investigation. In mature NHI governance, these failures should sit beside privilege anomalies and secret exposure alerts. Practitioners should escalate proof failure telemetry as identity security evidence, not merely transport noise.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a broader lifecycle view, see the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that keep proof-of-possession enforceable.

What this signals

Proof-of-possession will become a baseline expectation wherever machine identities touch high-value APIs. As teams absorb the operational lessons of bearer replay, the design question shifts from whether tokens expire to whether they are unusable outside the intended caller context. That makes binding, rotation, and revocation part of the identity programme rather than an API hardening afterthought.

Sender-constrained tokens create a useful control split between transport and application trust. mTLS is strongest where network paths are stable, while DPoP extends PoP to environments that cannot support client certificates cleanly. Teams should map which callers sit inside controllable infrastructure and which sit at the edge, then standardise validation policy accordingly.

Identity blast radius: the smaller the proof domain, the less useful a stolen credential becomes. With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, per Guide to the Secret Sprawl Challenge, proof binding only helps if key exposure is also reduced. Practitioners should pair PoP with lifecycle controls, not treat it as a substitute for them.

For practitioners

• Bind tokens to caller keys at the boundary Use mTLS for controlled internal paths and DPoP for diverse or public clients, then require the resource server to validate the proof before accepting the access token. Do not rely on token possession alone as evidence of legitimacy.
• Preserve client identity through proxies and gateways Verify that TLS termination, gateway policy, and backend forwarding preserve the client certificate thumbprint or DPoP context end to end. If the server cannot see the validated binding, the token should not be accepted.
• Set short but realistic rotation overlap windows Allow old and new keys to coexist only long enough for in-flight requests to finish, then revoke the old key and propagate the change quickly. Document the emergency revoke path before deployment.
• Treat proof failures as security signals Alert on cnf.jkt mismatches, repeated jti values, unexpected audience changes, and proof validation failures at gateways and resource servers. These events deserve incident review because they often indicate token theft or configuration drift.

Key takeaways

• Sender-constrained tokens reduce OAuth replay by requiring proof of private-key possession, not just token possession.
• The main implementation risk is operational consistency, especially across proxies, gateways, rotation windows, and replay detection.
• Teams that already struggle with secret lifecycle and offboarding should treat proof-of-possession as part of the same governance problem.

Key terms

• Sender-constrained token: An access token that can only be used by the caller that proves possession of the matching private key. This reduces replay risk because copying the token alone is not enough to gain access. The control relies on cryptographic binding and server-side verification at use time.
• Proof of possession: A verification pattern in which the caller must demonstrate control of a private key before a token is accepted. It changes OAuth from bearer semantics to bound semantics, which is especially important for service accounts, APIs, and machine identities that move through logs, gateways, and distributed systems.
• cnf claim: The OAuth confirmation claim used to bind a token to a particular key or certificate, often via a JWK thumbprint. It gives the resource server a reference point for checking whether the caller presenting the token is the one originally authorised to use it.
• Replay attack: An attack in which a stolen credential is reused to impersonate the original caller without reauthenticating. In machine identity environments, replay attacks are often enabled by logs, proxies, memory exposure, or poor lifecycle controls that leave credentials valid after exposure.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Scramble ID: Sender-constrained tokens and OAuth replay prevention. Read the original.