Refresh token security exposes the hidden SaaS attack path

At a glance

What this is: This is an analysis of refresh token security and how long-lived OAuth tokens create hidden SaaS attack paths that bypass standard authentication controls.

Why it matters: It matters because IAM and NHI teams need visibility, rotation, and anomaly detection for tokens that remain valid after initial authentication has already passed.

👉 Read Obsidian Security's analysis of refresh token protection and OAuth abuse

Context

Refresh token security is a governance problem because these credentials behave like long-lived non-human identities inside SaaS integrations. Once a refresh token is issued, it can keep generating access tokens even when SSO, MFA, and login monitoring never fire, which leaves IAM teams blind to the real control plane.

The article's central point is that token protection and token detection are not the same thing. Security teams can reduce exposure with rotation, lifetime limits, and sender-constraining, but they still need behavioural monitoring to spot abuse before data exfiltration completes. That starting position is typical for modern SaaS environments, where integrations outlive the assumptions built into human identity controls.

Key questions

Q: How should security teams reduce refresh token risk in SaaS environments?

A: Start with the basics that actually shrink blast radius: rotate tokens on every use, constrain sender context where possible, limit lifetimes by application sensitivity, and maintain fast revocation paths. Then add behavioural detection so you can spot active abuse, because static controls alone only reduce exposure after compromise, not during it.

Q: Why do refresh tokens complicate MFA and SSO enforcement?

A: Because refresh tokens operate after the original login has already succeeded. Once issued, they can keep minting new access tokens without prompting MFA or re-running SSO, which means the authentication stack can look clean while unauthorized activity continues through a valid bearer credential.

Q: What is the difference between token rotation and token detection?

A: Rotation changes the credential state to limit reuse, while detection identifies whether a token is already being abused. A team can rotate perfectly and still miss an attacker who used the token first. Effective programmes need both control-plane protection and runtime behavioural monitoring.

Q: When should organisations revoke refresh tokens aggressively?

A: Aggressive revocation is appropriate when an employee leaves, a vendor is breached, or a token shows anomalous behaviour that suggests replay or exfiltration. The key is knowing which tokens map to which resources so revocation is targeted, not a blunt disruption event.

Technical breakdown

Why refresh tokens behave like long-lived NHI credentials

Refresh tokens are bearer credentials that can be exchanged for new access tokens without repeating the original authentication flow. That makes them structurally different from short-lived access tokens, which expire quickly and narrow the attacker’s window. In SaaS environments, refresh tokens often sit inside app-to-app integrations, so their lifetime becomes the real exposure window. If an attacker steals one, they do not need to defeat MFA again. They can keep refreshing access as long as the token remains valid, which turns a single compromise into sustained unauthorized access.

Practical implication: Treat refresh tokens as persistent NHI assets and apply governance controls that reflect their longer operational lifespan.

Where refresh tokens are usually stolen

Token theft usually happens in one of four places: insecure client storage, interception in transit, compromised third-party vendors, or failed rotation logic. Browser storage and local files can expose tokens to script or device compromise. Transit interception is less common but still possible in misconfigured or hostile network paths. Third-party integrations widen the attack surface because a vendor breach can expose the tokens it stores on behalf of customers. Rotation failures are especially dangerous because they can leave multiple valid tokens alive long enough for an attacker to win the race.

Practical implication: Map token custody and rotation points across every integration, then remove any storage path you cannot monitor or revoke quickly.

Behavioral monitoring versus static token controls

Rotation, sender-constraining, and expiry limits reduce risk, but they do not tell you whether a token is already being abused. Detection depends on baselines for normal token use, including time of day, request volume, API targets, source location, and data access patterns. A token that suddenly pulls unusual data or shifts to high-volume automation may be compromised even if it is technically valid. That is why static controls need a behavioural layer. Without it, revocation is often reactive, broad, and late.

Practical implication: Build detections for anomalous token behaviour, not just expired or invalid token events.

Threat narrative

Attacker objective: The attacker wants persistent, low-friction access to SaaS data through trusted OAuth flows that evade MFA and SSO.

1. Entry occurs when an attacker steals a valid refresh token from storage, transit, or a compromised SaaS integration.
2. Escalation follows when the attacker exchanges that token for fresh access tokens and continues operating without reauthentication.
3. Impact lands when the attacker uses the trusted session path to query systems at scale and export sensitive SaaS data before detection.

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

Refresh token security is now a governance issue, not a narrow authentication problem. The article correctly shows that a valid refresh token can bypass the assumptions behind MFA and SSO. That means IAM teams must track not only who authenticated, but which non-human credentials can keep extending that access after the fact. Practitioner conclusion: refresh tokens need identity governance, not just application hardening.

Ephemeral access is not the same as ephemeral trust. Short-lived access tokens may reduce immediate blast radius, but the refresh token behind them can preserve a trusted path for days or weeks. This creates what we call an ephemeral credential trust debt, where the visible session expires faster than the hidden authority behind it. Practitioner conclusion: reduce the lifetime of the trust layer, not only the session layer.

Rotation without reuse detection is a partial control. The article's best-practice guidance is sound, but the deeper lesson is that rotation only works when replay attempts are treated as a compromise signal. If reuse detection is weak, an attacker can win the refresh race and keep the rotated family alive. Practitioner conclusion: pair rotation with immediate family invalidation and monitoring for replay patterns.

Behavioural monitoring is the difference between limiting exposure and actually finding abuse. Long-lived tokens can look legitimate until they start moving unusual data or operating from unexpected locations. That is why the control objective should shift from static token status to runtime token behaviour. Practitioner conclusion: teams should build token-specific detection logic into SaaS security operations.

Third-party OAuth scope is a supply-chain problem with identity consequences. A vendor breach can become your breach because the permissions and token custody model are shared. The article's incident examples reinforce a broader pattern already visible in NHI security: delegated access expands faster than most revocation processes. Practitioner conclusion: inventory every third-party token relationship and treat it as part of your NHI attack surface.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, which is consistent with refresh token replay risk and lifecycle weakness.
• The lifecycle view matters too, so compare this topic with NHI Lifecycle Management Guide when you are deciding how to govern issuance, rotation, and offboarding.

What this signals

Ephemeral credential trust debt: short-lived access tokens can make the environment look controlled while the underlying refresh token keeps the trust chain alive. Practitioners should assume that every SaaS integration with delegated OAuth access is a non-human identity problem until proven otherwise, then align detection and revocation workflows to that reality.

The control gap will widen as more business processes move through connected SaaS tools and agentic workflows. Teams that already map NHI lifecycle risk should add token custody, replay detection, and vendor breach response to their operating model, and anchor the programme in the NHI Lifecycle Management Guide and the OWASP Non-Human Identity Top 10.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, the practical next step is not another policy memo. It is an inventory of which integrations can keep issuing access after human authentication has ended.

For practitioners

• Implement token family rotation with reuse detection Require the authorization server to invalidate the old refresh token immediately after each exchange, and treat any replay of an invalidated token as a compromise event. This is the minimum control needed to stop token family reuse from becoming persistent access.
• Inventory every OAuth token relationship Map which users, applications, and third-party vendors can mint or store refresh tokens, then record the data sets those tokens can reach. Use that inventory to decide where revocation can be surgical and where broad invalidation is unavoidable.
• Set token lifetimes by app sensitivity Use shorter lifetimes for high-value SaaS applications and stricter limits for browser-based or shared environments, then review whether the configured lifetime matches the business impact of a stolen token. Keep the policy tied to exposure window, not convenience.
• Build behavioural detections for token abuse Alert on unusual request volume, new source locations, different API targets, and unexpected access times. These detections should feed incident response so teams can revoke the right token family before bulk exfiltration finishes.

Key takeaways

• Refresh tokens extend access beyond the moment of login, which makes them a persistent non-human identity risk inside SaaS environments.
• Rotation, sender-constraining, and lifetime limits reduce exposure, but only behavioural monitoring can reveal active token abuse before exfiltration completes.
• Security teams need token inventory, replay detection, and revocation processes that treat delegated OAuth access as part of NHI governance.

Key terms

• Refresh Token: A refresh token is a long-lived OAuth credential that can be exchanged for new access tokens without forcing the user or application to authenticate again. In practice, it becomes a persistent bearer credential, so whoever holds it can continue access until the token is revoked or expires.
• Token Family: A token family is the linked set of refresh tokens created through successive rotation events. It matters because reuse detection can invalidate the entire family when one token is replayed, which is how defenders stop an attacker from keeping access after rotation.
• Sender-Constraining: Sender-constraining ties a token to a specific client or transport context so the token is harder to replay elsewhere. It reduces theft value, but it does not replace rotation, monitoring, or revocation, because a compromised trusted context can still abuse a valid credential.
• Behavioral Baseline: A behavioural baseline is the normal pattern of token use across time, location, volume, and data access. Security teams use it to spot deviations that suggest compromise, even when the token itself still appears valid and properly scoped.

Deepen your knowledge

Refresh token security, OAuth governance, and NHI lifecycle risk are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for SaaS integrations and delegated access, it is worth exploring.

This post draws on content published by Obsidian Security: Refresh Token Security best practices for OAuth token protection. Read the original.