A stolen refresh token can keep generating valid access tokens until it is revoked or expires, which means the attacker can keep acting as the approved integration rather than as a noisy intruder. In practice, that turns delegated access into persistent access and makes revocation speed, scope limitation, and token inventory the decisive controls.
Why This Matters for Security Teams
A stolen third-party oauth refresh token is not just a credential leak, it is a delegated trust failure. The attacker does not need the user’s password, MFA, or an interactive session; they inherit the integration’s standing authority and can keep minting fresh access tokens until the refresh token is revoked, rotated, or expired. That makes the blast radius depend on the scopes granted, the lifespan of the token, and how quickly the organisation detects misuse. OWASP’s OWASP Non-Human Identity Top 10 frames this as an identity governance issue, not just a token hygiene issue. NHIMG’s Salesloft OAuth token breach shows how stolen delegated access can be abused at scale, while Entro Security found that 44% of NHI tokens are exposed in the wild and 91% of former employee tokens remain active after offboarding. In practice, many security teams encounter this only after the integration has already been used as a quiet backdoor rather than through intentional token review.
How It Works in Practice
OAuth refresh tokens are designed to reduce user friction, but that convenience creates a durable trust artifact. Once stolen, the attacker can repeatedly exchange the refresh token for new access tokens, often from outside the normal login flow. If the connected app has broad scopes, the attacker can read mail, sync data, alter records, or chain into adjacent SaaS systems without triggering a password reset. Current guidance from OWASP Non-Human Identity Top 10 is to treat these tokens as non-human identities with explicit lifecycle controls, not as invisible implementation details.
- Limit scopes to the minimum set the integration truly needs.
- Store refresh tokens in a managed secret store, not tickets, chats, or code.
- Track token inventory so owners can revoke the exact integration quickly.
- Use conditional access and anomaly detection on token use, not only on sign-in events.
- Prefer short-lived access tokens with tightly bounded refresh policies.
NHIMG’s Guide to the Secret Sprawl Challenge and The 52 NHI breaches Report both reinforce the same operational lesson: once secrets spread across tools, teams lose the speed needed for effective revocation. These controls tend to break down when the refresh token is embedded in a legacy connector or shared service account because ownership and revocation paths are unclear.
Common Variations and Edge Cases
Tighter refresh-token controls often increase operational friction, so organisations have to balance revocation speed against integration stability. For low-risk apps, that may mean narrower scopes and shorter refresh lifetimes; for business-critical SaaS connectors, it may require compensating controls such as approval workflows, token vaulting, and periodic reauthorisation. Best practice is evolving, but there is no universal standard for every app family yet, especially where vendors do not expose granular token telemetry.
Edge cases matter. A stolen refresh token is more dangerous when it belongs to a shared integration, a privileged admin app, or a workflow that can call downstream APIs with write access. It is also more dangerous when the organisation lacks a complete token inventory, because the team cannot tell whether the token is still active, duplicated, or reused elsewhere. In those environments, the attacker is not just impersonating one app; they may be inheriting an entire automation path. The NIST AI Risk Management Framework is useful here as a governance lens for accountability and monitoring, while the Anthropic report on AI-orchestrated cyber espionage is a reminder that automated systems can chain access quickly once a durable credential is available. In practice, refresh-token incidents become hardest to contain when delegated access has been overextended and no one can quickly prove which integration still needs the token.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Refresh tokens are NHI credentials that need lifecycle control and revocation. |
| NIST CSF 2.0 | PR.AC-4 | Stolen refresh tokens bypass normal user auth and require least-privilege access control. |
| NIST AI RMF | Autonomous misuse of delegated access needs governance, monitoring, and accountability. |
Inventory refresh tokens, rotate on schedule, and revoke immediately when compromise is suspected.
