When attackers compromised Salesloft in early 2025, they didn't need to maintain persistence through malware or backdoors. They simply used the refresh tokens already stored in Salesloft's environment-tokens that connected to customer Salesforce instances. Those refresh tokens had been authorized months or years earlier by users who had long since moved on to other projects, other teams, other companies. The tokens remained, granting access to 700+ organizations.
This incident exposed a fundamental blind spot in how organizations think about identity security. Refresh tokens operate outside traditional identity lifecycle controls. They don't require the user to re-authenticate, don't trigger MFA, and don't check current employment status. Understanding what are refresh tokens and how to use them securely has become critical for security teams defending against modern SaaS supply chain attacks.
Key Takeaways
- Refresh tokens are long-lived credentials that enable continuous access without re-authentication, often persisting indefinitely after initial OAuth consent.
- Bearer token architecture means whoever possesses a refresh token can use it-there's no additional verification of identity or device.
- Token rotation alone is insufficient because attackers who steal and use tokens first can maintain access while legitimate applications get invalidated.
- SaaS-to-SaaS attacks exploit refresh tokens stored in third-party integrations, enabling lateral movement that bypasses SSO and MFA entirely.
- Behavioral detection is essential because traditional security controls cannot distinguish between legitimate token usage and attacker abuse without baseline analysis.
What Is a Refresh Token?
A refresh token is a credential used to obtain new access tokens without requiring the user to re-authenticate. Think of it as the "long-lived key" to continuous access in OAuth 2.0 flows. While access tokens expire quickly-typically within 15 to 60 minutes-refresh tokens can persist for days, months, or indefinitely depending on configuration.
Most SaaS apps implement OAuth tokens as bearer tokens, something like a key. Whoever has this key can use it . There's no additional verification that the person or system presenting the token is the original authorized party. This design choice prioritizes developer convenience and user experience but creates significant security implications.
The refresh token exists in a different security tier than the access token it generates. While access tokens travel to resource servers (your actual data), refresh tokens only communicate with the authorization server to request new access tokens . This architectural separation is meant to limit exposure, but in practice, refresh token theft provides attackers with a renewable credential that functions independently of your SSO and MFA controls.
Why Refresh Tokens Exist: The Security vs. Usability Trade-off
The Problem They Solve
Access tokens expire quickly by design. Without refresh tokens, users would need to re-authenticate constantly-every 15 minutes in many implementations. Imagine your Salesforce integration requiring manual login every hour. Automation would break. User productivity would collapse. The business would grind to a halt.
Refresh tokens solve this friction by enabling continuous session management without repeated authentication ceremonies. When an access token expires, the application silently uses the refresh token to obtain a new one. Users experience seamless access. Automated workflows continue uninterrupted. The developer experience remains simple .
The Risk They Create
This convenience comes at a cost. Refresh tokens create persistent access without re-consent. Once issued, they continue functioning regardless of:
- Whether the original user still needs access
- Whether the user still works at your company
- Whether the user's device was compromised
- Whether the integration should still be trusted
Refresh tokens bypass MFA on every subsequent request . The initial OAuth consent may have required multi-factor authentication, but every token refresh afterward operates without additional verification. This creates an MFA bypass attack surface that traditional identity security tools cannot see.
Many refresh tokens have no expiration at all. Organizations discover tokens authorized years ago still actively accessing sensitive data. The tokens outlive employee tenure, project lifecycles, and security postures.
Access Token vs. Refresh Token: Understanding the Security Difference
Dimension Access Token Refresh Token Purpose Access resources directly Obtain new access tokens Lifetime Minutes (15-60 typical) Days to indefinite Sent to Resource server (your data) Authorization server only If stolen Limited damage window Persistent access granted MFA required No (after initial auth) No Scope Specific permissions Can request new access tokens with same scope Revocation Expires naturally Must be explicitly revoked Detection Usage visible in resource logs Refresh activity often invisible
The security difference is stark. A stolen access token provides a brief window of unauthorized access-measured in minutes. A stolen refresh token provides renewable access measured in months or years. Traditional security monitoring focuses on access token usage because that's where data access occurs, but the real persistence mechanism lives in the refresh token layer that most organizations don't monitor.
How Refresh Tokens Enable SaaS-to-SaaS Lateral Movement
The Persistence Problem
A refresh token is issued once during the initial OAuth consent flow. That single authorization event creates a credential that can function indefinitely. The original user may no longer need access-they moved to a different team, different project, different role. The original user may no longer work at your company-they left six months ago, but their authorized integrations remain active. The token continues functioning regardless .
This creates invisible attack paths through your SaaS supply chain. When you think about identity lifecycle, you think about user accounts. You offboard employees. You review access quarterly. You enforce least privilege. But refresh tokens authorized by those departed employees continue granting access through third-party integrations you may not even remember approving.
The Salesloft-Drift Attack Pattern
The Salesloft incident demonstrated how SaaS-to-SaaS lateral movement exploits refresh tokens stored in vendor environments. Attackers compromised Salesloft's infrastructure and found refresh tokens connecting to customer Salesforce instances. These weren't Salesloft's credentials-they were customer-authorized tokens that Salesloft stored to enable integration functionality.
The attackers used those tokens to access customer data across 700+ organizations. The tokens didn't know or care that they were being used by attackers instead of the legitimate Salesloft application. Bearer token architecture means possession equals authorization. There's no additional verification of the calling system's identity, no device fingerprinting, no behavioral analysis at the OAuth layer .
This pattern repeats across the SaaS ecosystem. CircleCI breach. Snowflake credential stuffing. Every vendor compromise potentially exposes the refresh tokens they store on behalf of customers. Your security posture becomes only as strong as your least secure integration partner.
Why Traditional Security Controls Miss Token Abuse
When attackers use stolen refresh tokens, they generate no failed login attempts to detect. There are no MFA challenges to fail. There are no geographic anomalies on user accounts because the token usage doesn't appear as user activity-it appears as legitimate application behavior.
Token usage looks like normal automation. The integration was authorized. The OAuth scopes were approved. The API calls match expected patterns. Traditional CASB and SSPM tools see authorized application activity, not account takeover or lateral movement .
SSO and MFA protect the initial consent flow, but OAuth tokens function independently of your SSO/MFA after issuance. The token doesn't re-validate through your identity provider on each use. It doesn't check whether the user is still employed. It doesn't verify the request originates from the expected infrastructure. For detailed analysis of how attackers bypass MFA through token compromise, see our guide on session hijacking techniques.
Refresh Token Rotation: Necessary but Insufficient
How Rotation Works
Refresh token rotation is now established as a fundamental security control in OAuth implementations . The mechanism works like this:
- Application uses refresh token to request new access token
- Authorization server issues new access token AND new refresh token
- Previous refresh token is immediately invalidated
- If the old token is used again, the server detects potential theft
This creates a detection mechanism for token replay attacks. If both the legitimate application and an attacker try to use the same refresh token, the server sees duplicate usage and can invalidate the entire token family .
Modern implementations must ensure rotation operates atomically using database locks to prevent race conditions that could create multiple simultaneously valid tokens for a single client . The IETF has standardized refresh token expiration parameters through draft-ietf-oauth-refresh-token-expiration to provide clearer lifecycle management.
What Rotation Catches
Token rotation effectively detects scenarios where:
- Attacker steals token and uses it while legitimate app also tries to use it
- Token is replayed from multiple sources simultaneously
- Legitimate application gets invalidated, triggering investigation
The automatic reuse detection invalidates entire token families when suspicious patterns emerge, limiting the blast radius of a single token compromise .
What Rotation Misses
Token rotation fails to protect against the most dangerous scenario: attacker who steals token and uses it first. If the attacker refreshes the token before the legitimate application does, they receive the new token and the legitimate app gets invalidated. From the authorization server's perspective, the attacker IS the legitimate application.
Rotation also provides no protection when tokens are never rotated because the legitimate app isn't actively using them. Dormant integrations with valid refresh tokens create persistent backdoors. The token sits unused for months, fully authorized, waiting for an attacker to discover it.
Organizations implementing token rotation often believe they've solved the refresh token security problem. They haven't. They've added a detection mechanism for one attack pattern while leaving the fundamental persistence problem unaddressed.
Platform-Specific Refresh Token Security Considerations
Single-Page Applications (SPAs)
Browser-based applications face unique refresh token challenges. Industry best practice now mandates 24-hour maximum refresh token lifetime for SPAs due to the inability to securely store credentials in browser environments . Intelligent Tracking Prevention (ITP) in Safari further limits storage options.
The recommended pattern is Backend-for-Frontend (BFF), where refresh tokens are stored server-side and the browser only holds short-lived access tokens. This architectural shift acknowledges that there isn't a way to safely store persistent refresh tokens in a browser and assure access by only the intended app.
Mobile Applications
Mobile platforms offer more secure storage options through Keychain (iOS) and Keystore (Android). This enables longer refresh token lifetimes without the same browser-based risks. However, malware on compromised devices can still extract tokens from these secure enclaves .
Mobile refresh tokens should still implement rotation and should expire after extended periods of inactivity. A token authorized on a device the user no longer owns represents ongoing risk.
Server-Side Applications
Backend services can store refresh tokens securely server-side, making them the "safest" token storage option from an architecture perspective. But server compromise exposes all stored tokens simultaneously. A single infrastructure breach can leak hundreds or thousands of refresh tokens connecting to customer environments-exactly what happened in the Salesloft incident.
Third-Party SaaS Integrations
This is where refresh token security becomes a supply chain problem. When you authorize a third-party SaaS integration, that vendor stores your refresh token in their environment. Your security is only as good as your vendor's security posture. Vendor breach equals your token breach.
Most organizations have dozens to hundreds of these integrations. Each one stores refresh tokens with varying levels of security. Each one represents a potential lateral movement path into your environment. Traditional vendor risk management tools provide very little visibility into how vendors store and protect your OAuth tokens. For more on managing these integration risks, explore our integration security insights.
Best Practices for Secure Refresh Token Implementation
Storage Security
Never store refresh tokens in browser local storage or session storage. These are vulnerable to XSS attacks. Use secure, HttpOnly cookies for browser-based applications to minimize exposure . The HttpOnly flag prevents JavaScript access, limiting XSS attack surface.
For server-side storage, encrypt refresh tokens at rest using strong encryption algorithms. Store encryption keys separately using key management services. Implement access controls limiting which services and accounts can read stored tokens .
Transport Security
HTTPS is mandatory for all token transmission. Configure TLS with strong cipher suites and disable older protocols like SSLv3 . This seems obvious, but many organizations discover legacy endpoints still accepting unencrypted connections during security audits.
Certificate pinning for mobile applications adds an additional layer of transport security, preventing man-in-the-middle attacks even if the device's certificate store is compromised.
Token Lifetime Management
Implement short-lived access tokens (15-60 minutes) paired with refresh tokens for session continuity . This limits the damage window if an access token is compromised while maintaining user experience.
For refresh tokens themselves, implement periodic rotation beyond usage. Best practice includes rotating refresh tokens after a set period (e.g., 30 days) even if unused, as routine security hygiene . This ensures dormant tokens don't persist indefinitely.
Configure absolute maximum lifetimes for refresh tokens. Even with rotation, tokens should have a hard expiration (e.g., 90 days) requiring full re-authentication. This forces periodic re-validation of the authorization relationship.
Grace Periods and Clock Skew
Implement short grace periods (approximately 5 minutes) after official expiration to accommodate network delays and clock synchronization issues without compromising security . This prevents legitimate requests from failing due to minor timing discrepancies while maintaining security boundaries.
Comprehensive Audit Logging
Security standards require logging every refresh token request with timestamp, user ID, client ID, and outcome . This enables detection of suspicious patterns such as:
- Tokens used from multiple geolocations within short timeframes
- Unusual refresh frequency (attackers may refresh more aggressively)
- Refresh requests from unexpected IP ranges or ASNs
- Token usage patterns diverging from historical baselines
These logs are useless without analysis. Organizations need behavioral baselines to distinguish normal variation from genuine threats. For strategies on continuous monitoring, see our article on continuous SaaS security monitoring.
Revocation Capabilities
Systems must support immediate revocation of all refresh tokens associated with a user account when fraud detection triggers or device compromise is suspected . This includes:
- Admin-initiated revocation for incident response
- Automated revocation when behavioral anomalies are detected
- User-initiated revocation through account security settings
- Bulk revocation when third-party integrations are removed
Revocation must invalidate the entire token family, not just the current token, to prevent attackers from using previously rotated but cached tokens.
OAuth Security Best Practices: What the IETF Says
The IETF published RFC 9700 in January 2025 as the updated Best Current Practice for OAuth 2.0 Security. This document extends the original threat model from RFCs 6749, 6750, and 6819 to incorporate practical security experiences gathered since OAuth 2.0's publication.
Key updates relevant to refresh tokens include:
- Deprecation of the Implicit Grant for public clients due to token exposure risks
- Mandatory PKCE (Proof Key for Code Exchange) for all OAuth flows, including those using refresh tokens
- Refresh token rotation as standard practice, not optional enhancement
- Sender-constrained tokens using mechanisms like DPoP (Demonstration of Proof-of-Possession) to bind tokens to specific clients
The IETF recognizes that the broader application of OAuth 2.0 has revealed new threats. Refresh tokens, originally designed for native applications, now power SaaS-to-SaaS integrations, API automation, and third-party data access at scales never envisioned. The security controls must evolve accordingly.
Detecting Refresh Token Abuse: From Awareness to Behavioral Analysis
The Detection Gap Most Organizations Face
Most organizations can answer these questions:
- OAuth consent logged: Yes, we see when users authorize applications
- Token issuance logged: Sometimes, depending on the authorization server
- Token usage monitored: Rarely, and only at the resource server level
- Token behavior baselined: Almost never
This creates a massive blind spot. You know an integration was authorized. You might know when tokens are issued. But you don't know how those tokens are being used or whether usage patterns indicate compromise.
Behavioral Indicators of Refresh Token Compromise
Token refreshed from IP address never seen before: The integration historically refreshed tokens from AWS us-east-1. Suddenly refresh requests originate from a residential ISP in Eastern Europe. Traditional security tools see authorized API activity. Behavioral analysis sees ASN deviation indicating potential compromise.
New ASN accessing your environment through established integration: The token was authorized months ago. The integration has been stable. Then refresh requests start coming from infrastructure that never previously accessed your environment. This pattern preceded the Salesloft breach discovery at multiple affected organizations.
Refresh frequency changed: Legitimate applications refresh tokens on predictable schedules tied to access token expiration. Attackers may refresh more aggressively to ensure persistent access or may refresh less frequently to avoid detection. Deviation from baseline refresh cadence indicates investigation.
Data access patterns diverging from historical baseline: After token refresh, the application suddenly accesses different data sets, different API endpoints, or different volumes than historical patterns. The integration was authorized for specific functionality. Behavioral change suggests the token is being used for unintended purposes. Learn more about detecting these patterns in our guide on detecting and blocking advanced phishing attacks.
The Knowledge Graph Advantage
Understanding refresh token behavior requires correlation across multiple dimensions:
- User who authorized the token
- Application receiving the token
- Infrastructure where token is stored
- Resources the token accesses
- Timing and frequency of token usage
- Geographic and network context of requests
Traditional security tools analyze these dimensions in isolation. A Knowledge Graph approach correlates relationships between SaaS applications, users, integrations, and data flows to identify toxic combinations and anomalous patterns invisible to point solutions.
When a refresh token authorized by a departed employee continues accessing sensitive data through a third-party integration from unexpected infrastructure, that's not three separate low-priority alerts. That's a high-confidence indicator of compromise requiring immediate investigation.
The Hidden Layer: Refresh Tokens in Your SaaS Supply Chain
Most organizations believe their biggest SaaS risk lives inside the applications they manage directly. In reality, the real exposure often sits one integration away. Third-party applications store refresh tokens connecting to your core SaaS platforms. Those vendors become part of your attack surface whether you realize it or not.
Consider a typical enterprise SaaS environment:
- Salesforce with 50+ authorized integrations
- Each integration stores refresh tokens with varying scopes
- Some tokens have read/write access to all records
- Some tokens were authorized years ago by users no longer with the company
- Token usage is invisible to your security team
This is the hidden layer where attackers operate. They don't need to compromise your Salesforce directly. They compromise the marketing automation platform that has admin-level refresh tokens to your Salesforce. They ride those trusted connections straight into your environment, bypassing SSO, MFA, and perimeter security entirely.
The operational burden of managing this manually is overwhelming. Spreadsheet inventories of integrations become outdated the moment they're created. Static point-in-time assessments miss the changing relationships between SaaS applications that create and eliminate risk continuously.
From Token Inventory to Token Behavior: What Security Teams Actually Need
Knowing refresh tokens exist is step one. Knowing how they're being used is step two. Knowing when usage patterns change is what stops breaches.
Security teams need to answer:
- Which refresh tokens are currently accessing our data? Not which were authorized, but which are actively being used right now.
- What permissions do those tokens have? Read-only or read/write? Specific objects or all data?
- Who authorized them and when? Is the authorizing user still with the company? Still in the same role?
- Where are the tokens being used from? Expected infrastructure or anomalous sources?
- How has usage changed over time? Stable patterns or suspicious deviations?
- What would happen if we revoked them? Which business processes would break?
Traditional security tools provide inventory (static list of integrations) or configuration (OAuth scopes at time of authorization). Neither answers the operational questions security teams actually need to make risk decisions.
Behavior vs. inventory is the fundamental distinction. An inventory tells you a refresh token exists. Behavioral analysis tells you whether it's being abused.
Obsidian's Approach: Behavioral Detection for the Hidden Layer
Refresh tokens authorized months or years ago are still accessing your sensitive data today. Many were authorized by users who no longer work at your company. Some are stored in vendor environments you can't audit. Traditional security tools can't see them, can't monitor their usage, and can't detect when they're compromised.
Obsidian discovers refresh tokens across your SaaS environment, tracking how they're being used and detecting when usage patterns indicate compromise. Our Knowledge Graph correlates token behavior with user context, application relationships, and infrastructure patterns to identify toxic combinations invisible to point solutions.
We detect:
- Refresh tokens used from unexpected IP addresses or ASNs
- Tokens authorized by departed employees still accessing data
- Usage pattern changes indicating potential compromise
- Overprivileged permissions that create unnecessary blast radius
- Stale integrations with admin access that should be revoked
See which refresh tokens would survive your next employee offboarding. Discover the integrations you didn't know existed. Understand which vendor breach would expose your most sensitive data. Get behavioral context to make informed risk decisions instead of managing spreadsheets.
Stop token compromise before it becomes a breach. Obsidian provides the visibility and detection capabilities security teams need to govern the hidden layer between their SaaS applications.
Conclusion
Understanding what are refresh tokens and how to use them securely is no longer optional for security teams defending modern SaaS environments. These long-lived credentials enable continuous access without re-authentication, creating persistent attack paths that bypass SSO and MFA entirely.
The Salesloft incident proved that refresh tokens stored in third-party integrations represent genuine supply chain risk. When vendors are compromised, the refresh tokens they store become weapons attackers use to access customer data at scale. Traditional security controls focused on user accounts and authentication events cannot detect this abuse because token usage appears as legitimate application activity.
Actionable next steps for security teams:
- Audit existing refresh tokens across your SaaS environment to understand current exposure
- Implement token rotation as baseline hygiene, recognizing its limitations
- Establish behavioral baselines for token usage to enable anomaly detection
- Review third-party integrations to understand which vendors store your refresh tokens
- Deploy behavioral detection capabilities that monitor token usage patterns, not just authorization events
- Create incident response playbooks specifically for refresh token compromise scenarios
- Educate development teams on secure token storage and rotation implementation
The security vs. usability trade-off that refresh tokens represent isn't going away. Organizations need continuous access for automation and user experience. But that convenience cannot come at the cost of invisible, unmonitored persistence mechanisms that attackers exploit for lateral movement.
Behavior vs. inventory is the critical distinction. Knowing which tokens exist is table stakes. Knowing how they're being used and detecting when usage patterns change is what prevents breaches. Security teams need tools that provide operational reality, not static snapshots-tools that understand the hidden layer where refresh tokens operate and where attackers move undetected.
The refresh tokens authorized in your environment today will outlive employee tenure, project lifecycles, and security postures unless you actively govern them. Make refresh token behavior visible. Make anomalous usage detectable. Make your SaaS supply chain defensible.
