The repeated use of a long-lived OAuth refresh token to obtain new access tokens without asking the user to authenticate again. It turns a single captured credential into durable session access, which is why revocation speed and token telemetry matter so much in identity governance.
Expanded Definition
refresh token replay is a session persistence abuse pattern in OAuth 2.0 where a stolen refresh token is used repeatedly to mint fresh access tokens, often without triggering a new user prompt. In NHI operations, the risk is not the access token itself but the long-lived bearer value that can keep renewing access after the original theft.
Definitions vary across vendors on how they classify this event. Some treat it as a token theft issue, while others group it under session hijacking or credential replay. For governance purposes, the practical distinction is whether the token can be reused after first compromise and whether rotation, binding, or revocation controls can invalidate the replay path. NIST Cybersecurity Framework 2.0 provides a useful governance lens for this by tying identity protection, anomaly detection, and response outcomes to real operational controls, even though it does not name refresh token replay explicitly. For a broader NHI context, the pattern overlaps with the token exposure and lifecycle failures discussed in the Guide to the Secret Sprawl Challenge.
The most common misapplication is assuming an expired access token means the compromise is over, which occurs when the refresh token remains valid and unrevoked.
Examples and Use Cases
Implementing replay resistance rigorously often introduces more session friction and operational complexity, requiring organisations to weigh user continuity against tighter token controls and faster invalidation.
- A SaaS integration stores a refresh token in a CI/CD variable, and an attacker who reaches the pipeline can mint access tokens long after the initial leak. This mirrors the broader secrets exposure patterns described in the State of Secrets Sprawl 2026.
- An employee offboards, but their oauth refresh token remains active in a delegated mailbox or calendar connector, allowing continued access until manual revocation catches up.
- A mobile app refresh token is copied from a compromised device backup and replayed from a new location, bypassing the normal login flow because the authorization server still trusts the token family.
- A third-party monitoring tool uses one shared NHI across multiple tenants, so one stolen refresh token can be replayed across several connected environments if the issuer does not bind the token to device, client, or audience.
- In incident response, analysts correlate repeated token refreshes from unusual IPs with the compromise timeline, then revoke the grant and rotate downstream secrets. The NIST Cybersecurity Framework 2.0 is often used to structure that detection-to-response workflow.
Why It Matters in NHI Security
Refresh token replay is one of the clearest examples of how a single credential can become durable access across systems, teams, and time. In NHI environments, that durability is dangerous because service accounts, integrations, and agentic workflows often depend on unattended token renewal. If replay is not constrained, attackers do not need to keep stealing new secrets; they only need one surviving refresh token to keep re-entering the trust boundary.
NHIMG research shows how persistent token exposure becomes a systemic problem, not a one-off event: in The 2025 State of NHIs and Secrets in Cybersecurity, 91% of former employee tokens remain active after offboarding, and 44% of NHI tokens are exposed in the wild. That combination means replay risk often survives both detection and personnel change unless revocation is automated. The Salesloft OAuth token breach is a reminder that token abuse can translate directly into downstream data access, even when the original application boundary appears intact.
Organisations typically encounter the operational impact only after abnormal API access, offboarding review, or a third-party breach reveals that token renewal continued unnoticed, at which point refresh token replay becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 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-02 | Refresh token replay is enabled by weak secret and token lifecycle handling. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access control must prevent stolen tokens from preserving access. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous verification rather than trust from a previously issued token. |
Treat token replay as an identity control failure and tighten access granting, monitoring, and revocation.
