Refresh token security exposes the hidden SaaS attack path

At a glance

What this is: This article explains why refresh tokens create a hidden SaaS attack path and shows that behavioural monitoring is the control that exposes abuse before data leaves the environment.

Why it matters: IAM and security teams need to treat OAuth refresh tokens as long-lived bearer credentials, because revocation and rotation reduce exposure but do not replace detection, especially across third-party SaaS integrations.

Context

Refresh tokens are long-lived OAuth credentials that let applications obtain new access tokens without repeating user authentication. In SaaS environments, that makes them materially different from short-lived access tokens, because they can persist across SSO and MFA boundaries and continue working after initial compromise.

The governance gap is visibility. Teams can usually see the application and the integration, but not the token abuse unfolding between SaaS platforms, third-party vendors, and connected data stores. That is why refresh token security belongs in IAM, NHI governance, and incident response at the same time.

Obsidian Security frames this as a detection problem as much as a protection problem. The operational question is not whether tokens can be stolen, but whether the programme can spot abnormal token use quickly enough to limit exfiltration and lateral movement across connected SaaS environments.

Key questions

Q: What breaks when refresh tokens are stolen from SaaS environments?

A: When a refresh token is stolen, the attacker can mint new access tokens without repeating SSO or MFA, so the compromise survives beyond the original login event. The real failure is that the credential remains valid long enough to support quiet data access and exfiltration before anyone notices.

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: How can security teams tell whether refresh token handling is actually safe?

A: The key signal is whether a stolen or replayed refresh token can still mint new access tokens after it has already been used once. If reuse is possible, the token behaves like standing privilege. Safe handling requires single-use rotation, invalidation on replay, and short-lived access token support.

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 outlive authentication controls

Refresh tokens are bearer credentials, which means possession is enough to obtain new access tokens. Because they are designed for continuity, they survive beyond a single login session and can function for days or weeks depending on policy. That breaks the assumption that SSO and MFA are the primary enforcement points. Once a valid refresh token exists, the authorization server often treats the request as legitimate unless additional signals are present. In practice, that moves the security problem from interactive authentication to token lifecycle governance and abuse detection.

Practical implication: treat refresh tokens as governed credentials, not as harmless session helpers.

Token rotation and reuse detection mechanics

Rotation replaces the refresh token after each successful exchange, while reuse detection flags an old token being presented again after invalidation. The control value is not just shorter lifetime, but the ability to recognise replay and kill the token family when suspicious reuse occurs. Without atomic state updates, token-family tracking, and immediate invalidation, rotation can create race conditions that leave multiple valid credentials active at once. That is why rotation alone is not equivalent to compromise detection; it is only effective when the server can prove a token was reused after it should have died.

Practical implication: implement rotation as a stateful control with reuse detection, not as a simple expiry setting.

Behavioral monitoring for refresh token abuse

Behavioural monitoring looks for deviations in access pattern, timing, volume, and source location. A token that suddenly reaches new data sets, shifts to unusual hours, or generates request bursts is often behaving more like an attacker tool than an expected application flow. This matters because stolen refresh tokens frequently look valid to the platform and invisible to classic authentication alerts. In SaaS estates, the only reliable clue may be that the token's behaviour no longer matches its historical baseline. That makes anomaly detection the practical control that turns token security from prevention-only into live compromise detection.

Practical implication: baseline normal token behaviour and alert on deviations before exfiltration completes.

Threat narrative

Attacker objective: The attacker wants sustained, low-friction access to SaaS data and integrations long enough to exfiltrate information before defenders notice the compromise.

1. Entry occurs when an attacker steals or intercepts a valid refresh token from storage, a third-party integration, or another exposed SaaS trust path.
2. Credential access follows when the attacker exchanges that refresh token for fresh access tokens without triggering SSO or MFA.
3. Escalation happens as the attacker reuses valid OAuth scopes to query connected SaaS applications, expand visibility, and move through trusted integrations.
4. Impact occurs when the attacker exports customer or business data and remains active until the token family is revoked or detected through behavioural anomalies.

Breaches seen in the wild

• JetBrains GitHub plugin token exposure: A flaw in the JetBrains GitHub plugin could send IDE users' GitHub tokens to an attacker via a crafted pull request. Fixed; tokens to be revoked.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Refresh token security is an NHI governance problem disguised as an authentication problem. Refresh tokens are long-lived bearer credentials, so the governance issue is not initial sign-in but what happens after a token outlives the authentication event that created it. That makes lifecycle control, revocation, and abuse detection central to the identity programme. Practitioners should stop treating refresh tokens as a peripheral OAuth detail and manage them as privileged non-human credentials.

Detection latency, not token theft alone, is the decisive failure mode. The article shows that attackers can use a valid refresh token to mint fresh access tokens and exfiltrate data before revocation catches up. This means the hidden SaaS attack path exists because security teams rely on controls that only fire at login time. The implication is that token behaviour must become an auditable security signal, not just a transport mechanism.

Token rotation without reuse detection is incomplete governance. Rotation shortens the exposure window, but the article makes clear that an attacker who uses the token first can still win the race and maintain access. That is a standing-credential persistence problem, not a simple expiry problem. Practitioners should regard any rotation programme without family-level invalidation as partial control, not closed-loop protection.

Third-party SaaS integrations expand the identity blast radius beyond the primary application. The article's strongest risk signal is not a single compromised app, but the bridge it creates into connected systems that inherit OAuth scopes and trust. That is the hidden SaaS supply chain problem: accountability becomes fragmented once tokens are stored by vendors and reused across multiple services. Security teams need to govern those delegated paths as part of the access model, not after a breach notification arrives.

Refresh-token abuse forces identity teams to rethink what 'normal' access means. If valid token use looks identical to legitimate application traffic, then traditional authentication metrics lose most of their value. This is where behavioural baselining becomes an identity control, because the programme must judge whether a token's use still matches its intended purpose. The practical conclusion is that SaaS identity monitoring has to move from event counting to context-aware detection.

From our research library:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
• Read next: Token and Session Security Guide

What this signals

Hidden SaaS token paths change the monitoring model. Security teams can no longer rely on login events alone when valid bearer credentials can keep moving between applications after initial authentication. The practical shift is from account-centric alerting to token-centric behaviour analysis, especially where third-party integrations extend trust outside the core tenant.

Refresh-token governance now belongs in identity lifecycle and incident response. Revocation matters at offboarding, after vendor compromise, and when reuse is detected, but those actions work only if the organisation can identify the relevant token family first. That is why token inventory and behavioural baselines are becoming core programme controls rather than optional hardening.

71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs. The same governance weakness applies here: long-lived credentials outlast the review cycle, so the control point shifts from periodic review to issuance and reuse detection.

For practitioners

• Implement token-family rotation with reuse detection Use atomic updates so each refresh exchange invalidates the previous token and any reused token family is revoked immediately.
• Baseline token behaviour across SaaS apps Track normal access patterns, timing, volume, and source location so deviations can be flagged before exfiltration completes.
• Inventory third-party OAuth relationships Map which vendors, applications, and users can mint tokens into each SaaS platform so revocation decisions are precise during an incident.
• Set sensitivity-based token lifetimes Use shorter lifetimes for high-value SaaS apps and pair them with anomaly detection rather than relying on expiry alone.
• Integrate revocation into incident playbooks Ensure employee departure, vendor breach notification, and suspicious token reuse all trigger immediate token invalidation workflows.

Key takeaways

• Refresh tokens create a hidden SaaS attack path because they continue working after the authentication event that created them.
• The article shows that attackers can use valid tokens to exfiltrate data before revocation catches up, which makes detection speed the real control variable.
• Rotation, lifetime limits, and sender-constraining help, but behavioural monitoring is what exposes active abuse in time.

Key terms

• Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
• 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.
• Reuse Detection: Reuse detection is the control that flags when an invalidated token is presented again, indicating possible theft or replay. It turns token lifecycle management into an active compromise signal. For SaaS identity programmes, reuse detection matters because it reveals abuse that normal authentication logs will miss.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.

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 building or maturing an IAM programme, it is worth exploring.