Refresh token governance is the missing layer in SaaS identity security

At a glance

What this is: This is an analysis of refresh tokens as persistent OAuth credentials and the security blind spots they create when they outlive user and integration lifecycles.

Why it matters: It matters because IAM and NHI teams cannot treat OAuth consent as a one-time event when refresh tokens can bypass MFA, persist after offboarding, and enable SaaS-to-SaaS lateral movement.

By the numbers:

• 700+ organizations.
• Access tokens typically expire within 15 to 60 minutes.

👉 Read Obsidian Security's analysis of refresh token risk and secure handling

Context

Refresh tokens are a form of non-human identity because they behave as durable credentials that keep systems authenticated after the original user action is complete. The governance problem is that identity controls usually focus on the person at login, while refresh token risk lives in the integration layer, where consent, storage, and revocation are often weakly managed.

The article uses the Salesloft compromise to show how a token authorized months or years earlier can still grant access even after the user has changed teams or left the company. That is not an edge case. It is a common lifecycle failure in SaaS estates, especially where third-party apps store customer tokens on their behalf.

For IAM and NHI practitioners, the core issue is not whether OAuth is broken, but whether organizations are governing token persistence as rigorously as they govern accounts. In practice, refresh tokens create a parallel access path that can survive offboarding, bypass step-up checks, and evade conventional visibility tools.

Key questions

Q: How should security teams govern refresh tokens in SaaS environments?

A: Treat refresh tokens as durable non-human identities with owners, expiry dates, and revocation procedures. Map where they are stored, who can redeem them, and which third parties hold them. Then tie offboarding, access review, and incident response to token custody, not just to user accounts.

Q: Why are refresh tokens riskier than access tokens after compromise?

A: Access tokens are usually short-lived, so their damage window is limited. Refresh tokens can mint new access tokens repeatedly, which means possession can preserve access for months or longer. That makes the refresh token the persistence mechanism and the access token only the temporary execution credential.

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

A: Rotation replaces an old refresh token with a new one and can expose replay attempts, while revocation ends the credential’s ability to issue any new tokens. Rotation helps with detection and hygiene, but revocation is what contains compromise. Organisations need both, plus family-wide invalidation when theft is suspected.

Q: When should organisations treat SaaS token use as an incident?

A: When token activity deviates from the integration baseline, comes from unexpected infrastructure, or appears after a user has left the company, treat it as a potential incident. Refresh token abuse often looks legitimate in logs, so behavioural drift is more useful than failed login alerts for triage.

Technical breakdown

How refresh token architecture creates persistent SaaS access

OAuth separates access tokens from refresh tokens to reduce friction. Access tokens are short-lived and used at the resource server, while refresh tokens are presented only to the authorization server to mint new access tokens. That design improves usability, but it also creates a bearer credential whose possession is enough to keep renewing access. In NHI terms, the token becomes an autonomous credential with no inherent awareness of employment status, device trust, or current business need. If the refresh token is stored in a SaaS integration, the integration effectively becomes a long-lived identity holder until explicit revocation occurs.

Practical implication: Treat refresh tokens as durable NHI assets and inventory them separately from user accounts and access tokens.

Why token rotation helps, but does not eliminate replay risk

Rotation replaces each used refresh token with a new one and invalidates the previous token, which can expose replay attempts when the same credential is used twice. That is useful, but not sufficient. If an attacker redeems the token before the legitimate application does, the attacker can win the race and preserve access while the real client is invalidated. Rotation also depends on atomic server-side enforcement, short grace periods, and the ability to revoke the full token family when compromise is suspected. Without those controls, rotation becomes a partial signal rather than a complete containment mechanism.

Practical implication: Use rotation with strict revocation logic and race-condition-safe implementation, not as a standalone defence.

Behavioral detection for refresh tokens and SaaS-to-SaaS abuse

Refresh token abuse often looks normal at the API layer because the calls are made by an authorized application, not an obviously hijacked user account. That is why SSO logs, MFA prompts, and user-centric alerts miss the attack. The better signal is behavioural drift, such as refreshes from new geographies, unusual request frequency, or access patterns that diverge from the integration baseline. In SaaS supply chain attacks, the credential may be valid even when the actor behind it is not. Detection therefore has to focus on the token’s usage pattern, not only on whether the token was originally issued correctly.

Practical implication: Build anomaly detection around token behaviour and integrate those alerts into incident response for SaaS exposure.

Threat narrative

Attacker objective: Maintain renewable access to downstream SaaS data through stolen refresh tokens without triggering the usual identity controls.

1. Entry via compromise of a third-party SaaS environment that stored customer-authorized refresh tokens for downstream access.
2. Escalation through repeated token redemption that bypassed user re-authentication, MFA, and current employment checks.
3. Impact through SaaS-to-SaaS lateral movement into customer Salesforce environments and broad downstream data access.

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 persistence is a non-human identity problem, not just an OAuth hygiene problem. The control failure is lifecycle mismatch. Organisations often revoke user access while leaving integration tokens untouched, which means a credential can outlive the user who approved it by months or years. That gap turns old consent into standing access. Practitioners should govern refresh tokens as first-class NHI assets with ownership, expiry, and revocation requirements.

Ephemeral access does not remove the trust debt embedded in bearer-token design. A short-lived access token can reduce exposure, but the refresh token underneath still defines who can keep reissuing access. The real risk is that possession alone is authorization, so compromise of the token issuer or storage layer is enough to preserve access without a fresh identity check. Teams should therefore pair token TTLs with source-of-truth controls for consent and revocation.

Refresh token rotation creates detection value, but only if organisations are prepared to act on the signal. A replay event can show that a token was copied or reused, yet many environments lack the operational process to invalidate the token family quickly enough. That makes rotation necessary hygiene, not a complete defence. Practitioners should treat every replay alert as a potential SaaS supply chain incident, not an isolated authentication event.

Third-party integrations are now part of the identity attack surface. The article’s core lesson is that vendor-held tokens can become the weakest link in a downstream enterprise estate. That widens the governance boundary for IAM and NHI programmes, because access reviews must extend to the application that stores the token, not just the user who once consented. Security teams should map token custody wherever SaaS integrations store customer credentials.

Identity blast radius is the right concept for refresh token governance. Once a refresh token is compromised, the question is not whether one account was affected, but how far the token family and linked integrations can be used before containment occurs. That shifts the security conversation from login events to reachable systems and stored credentials. Practitioners should measure blast radius, not just authentication success rates.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
• NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding controls reduce the persistence window for durable credentials.

What this signals

Ephemeral credential trust debt: organisations that rely on OAuth consent without explicit token custody controls accumulate hidden standing privilege. The practical result is that offboarding and access review work only if they reach the integration layer, not just the directory. With 44% of NHI tokens exposed in the wild in our research, the persistence problem is already structural, and the control answer starts with lifecycle ownership.

SaaS programmes should assume that third-party integrations are part of the identity perimeter and bind them to the same control expectations as human accounts. That means integrating token governance with NIST Cybersecurity Framework 2.0 and, where agent behaviour is involved, extending review logic to OWASP Non-Human Identity Top 10 guidance.

The next maturity step is operational, not conceptual. Teams need revocation workflows, replay detection, and ownership records that let them act within minutes when a token is misused. Without that, rotation only documents exposure after the fact instead of shrinking the reachable blast radius.

For practitioners

• Inventory all refresh tokens and their custodians Build a register of every SaaS integration that stores refresh tokens, including the vendor, owning team, approval date, and revocation path. Separate customer-managed tokens from vendor-held tokens so offboarding and access reviews can target the real custody point.
• Enforce rotation with family-wide revocation Require refresh token rotation, but also verify that the authorization server can invalidate the entire token family when replay or theft is suspected. Test the revocation workflow during tabletop exercises so response is not limited to manual ticketing.
• Monitor token behaviour, not only login events Baseline refresh frequency, source IP ranges, geographic patterns, and application context for each integration. Alert on drift such as unusual refresh bursts, new ASN usage, or token activity outside normal business hours.
• Tie offboarding to OAuth consent removal When an employee leaves or changes role, remove associated OAuth grants and verify that third-party apps no longer hold active tokens. Offboarding is incomplete if the user account is disabled but the integration token remains valid.
• Apply zero standing privilege to durable credentials Use short-lived access where possible, but assume refresh tokens are standing privileges unless explicitly governed. Where business needs require persistence, add ownership, expiry, and periodic re-authorization checks.

Key takeaways

• Refresh tokens create durable access paths that outlive the user and often outlast the control assumptions built into IAM programmes.
• Offboarding failures and third-party token custody are the main reasons refresh token risk becomes a SaaS supply chain problem.
• The practical response is token inventory, family-wide revocation, and behavioural detection tied to the integration layer.

Key terms

• Refresh Token: A refresh token is a long-lived OAuth credential used to obtain new access tokens without forcing re-authentication. It usually acts as a bearer token, so possession is enough to redeem it. In NHI governance, it should be treated as a durable credential with lifecycle controls, ownership, and explicit revocation.
• Bearer Token: A bearer token is a credential that authorizes whoever presents it, with no extra proof of identity at use time. That design is convenient for automation but dangerous when stored or exfiltrated, because the token itself becomes the access mechanism. For practitioners, bearer tokens demand strict storage, expiry, and monitoring controls.
• Token Rotation: Token rotation is the practice of replacing a refresh token with a new one after use and invalidating the previous token. It helps detect replay and reduces reuse risk, but it does not solve compromise on its own. Strong implementations combine rotation with atomic invalidation, telemetry, and full-family revocation.
• SaaS-to-SaaS Lateral Movement: SaaS-to-SaaS lateral movement happens when attackers use one cloud application or integration to reach another connected service. It is common when refresh tokens or API credentials are stored by third-party vendors on a customer’s behalf. The risk is that one compromise can open several downstream tenants at once.

Deepen your knowledge

Refresh token governance and lifecycle control 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 that store durable credentials, it is worth exploring.

This post draws on content published by Obsidian Security: What Are Refresh Tokens and How to Use Them Securely. Read the original.