Security teams face an uncomfortable truth in 2026: attackers have quietly shifted their focus from stealing passwords to stealing something far more valuable, the tokens that grant access without them. Token theft has become the primary method for bypassing authentication controls, enabling attackers to ride trusted connections straight into protected environments without triggering a single MFA prompt or failed login alert.
Most organizations believe their SSO and MFA implementations protect them from unauthorized access. In reality, authentication tokens function independently of those controls. Once issued, tokens become bearer credentials, and whoever has the token can use it, no questions asked. This fundamental characteristic transforms tokens into high-value targets that bypass the security controls organizations have spent years implementing.
The risk is not theoretical. The Salesloft-Drift incident showed how OAuth tokens stolen from a vendor breach extended access to more than 700 companies. The CircleCI compromise exposed API tokens that attackers used to access customer environments. Microsoft has documented widespread adversary-in-the-middle campaigns capturing session tokens in real-time, completely bypassing MFA protections.
Key Takeaways
- Token theft bypasses passwords and MFA entirely: stolen tokens grant immediate access without authentication challenges
- Refresh tokens survive password resets: attackers maintain persistent access even after incident response actions
- Stolen tokens are valid tokens: traditional security tools struggle to distinguish legitimate usage from malicious activity
- Detection requires behavioral monitoring: IP deviation, User-Agent changes, and data access anomalies become critical signals
- Incident response must include token revocation: password resets alone leave attackers with continued access through stolen tokens
What is Token Theft?
Token theft is the act of stealing authentication tokens to gain unauthorized access to systems and data without possessing legitimate credentials. Unlike traditional credential theft that requires attackers to know usernames and passwords, token theft exploits the bearer token problem: whoever has the token can use it.
Tokens serve as proof of authentication. When users successfully log in, completing passwords, MFA challenges, and any other verification steps, systems issue tokens that say "this request comes from an authenticated user." Those tokens then accompany subsequent requests, eliminating the need to re-authenticate for every action.
This design creates efficiency for legitimate users and a critical vulnerability when tokens fall into the wrong hands. A stolen token grants attackers the same access as the legitimate user who originally authenticated, without requiring the attacker to know passwords, bypass MFA, or trigger authentication monitoring systems.
The shift from credential theft to token theft represents a fundamental change in attacker methodology. Passwords can be protected with MFA. Tokens bypass MFA entirely because they're issued after authentication completes. Traditional security controls focus on preventing unauthorized authentication. Token theft occurs after authentication succeeds, operating in the blind spots where many security teams lack visibility.
Organizations implementing SaaS security controls must understand this distinction. The authentication layer and the authorization layer are not the same. Tokens live in the authorization layer, where they quietly extend trust across applications, integrations, and API connections, often one integration away from environments security teams believe they've locked down.
Types of Tokens Attackers Target
OAuth Tokens
OAuth tokens enable applications to access resources on behalf of users without sharing passwords. This delegation model powers the integrations that connect modern SaaS environments, but it also creates persistent access paths that survive traditional security responses.
Access tokens grant temporary access to specific resources. These short-lived credentials typically expire within minutes to hours, limiting the window of opportunity for attackers who steal them. However, access tokens still bypass authentication entirely, requiring no password or MFA.
Refresh tokens present a far more serious threat. These long-lived credentials generate new access tokens indefinitely, often remaining valid for months or years. A stolen refresh token grants persistent access that survives password resets, MFA re-enrollment, and most incident response actions security teams typically perform.
The distinction between access token vs refresh token matters critically during investigations. Revoking access tokens provides temporary relief. Revoking refresh tokens actually terminates the attacker's ability to maintain persistence.
OAuth tokens function independently of SSO and MFA. Once a user authorizes an OAuth application, completing whatever authentication challenges the identity provider requires, the application receives tokens that work regardless of subsequent password changes or MFA policy updates. This independence makes OAuth token theft particularly valuable to attackers establishing long-term access.
Most SaaS apps implement OAuth tokens as bearer tokens. No cryptographic proof of token ownership exists. The token itself serves as the only credential. Whoever presents a valid token receives access, whether they legitimately obtained it or stole it from someone else.
Session Tokens
Session tokens, typically implemented as cookies, maintain authenticated sessions after users complete login flows. When users successfully authenticate, including completing MFA challenges, applications issue session tokens that identify subsequent requests as coming from that authenticated session.
These tokens enable the seamless experience users expect. Log in once, then browse multiple pages, access different features, and perform various actions without re-authenticating constantly. The session token accompanying each request proves the user already authenticated.
For attackers, a stolen session token means inheriting a fully authenticated session. The attacker doesn't need to know the password. The attacker doesn't need to bypass MFA. The authentication already happened. The session token proves it. The application has no mechanism to verify that the entity presenting the token is the same entity that originally authenticated.
Session hijacking attacks specifically target these tokens. Once captured, session tokens grant immediate access to everything the legitimate user can access. The attack surface extends beyond traditional phishing, as malware, network interception, and cross-site scripting vulnerabilities all provide paths to session token theft.
Organizations implementing strong authentication controls often overlook session token security. MFA protects the initial login. Session tokens protect everything after that. Compromise the token, bypass the authentication.
API Tokens & Keys
API tokens and keys provide programmatic access to services, enabling automation, integrations, and machine-to-machine communication. Unlike OAuth tokens tied to user authorization flows, API keys often function as static credentials with indefinite lifespans.
These credentials appear everywhere: embedded in code repositories, stored in configuration files, captured in application logs, and hardcoded into build pipeline scripts. The operational convenience of long-lived API tokens creates security risk, and a single exposed key can unlock access to multiple services.
API key security challenges compound in SaaS environments where keys enable access across application boundaries. A stolen API key from one service might grant access to connected services through integration chains. The blast radius extends beyond the application that issued the key.
API token management becomes critical as organizations scale their SaaS footprint. Each represents a potential access path if the associated credentials are compromised.
The persistence of API tokens creates detection challenges. Unlike session tokens that expire when users log out, API keys remain valid until explicitly revoked. Attackers who steal API tokens gain access that survives password resets, user deactivation, and many other security responses that would terminate human access.
How Attackers Steal Tokens
Adversary-in-the-Middle (AiTM) Phishing
Adversary-in-the-middle phishing represents a sophisticated evolution of traditional phishing attacks. Rather than creating fake login pages that capture credentials, AiTM attacks proxy traffic between victims and legitimate authentication services.
The attack flow works like this: the attacker sends a phishing email with a link to their infrastructure. When the victim clicks, the attacker's server proxies the request to the real login page. The victim sees the legitimate authentication interface with the correct domain in the browser, valid SSL certificate, and real MFA prompts.
The victim completes authentication on the actual service. They enter their real password on the real login page. They approve the real MFA challenge from their real authentication app. Everything appears normal because it is normal, except the attacker sits in the middle, capturing every request and response.
When the legitimate service issues session tokens after successful authentication, those tokens flow through the attacker's proxy. The attacker captures the tokens, then forwards them to the victim's browser. The victim successfully logs in, completely unaware their session tokens were stolen in transit.
This MFA bypass attack defeats phishing-resistant authentication because the victim actually completes legitimate MFA. The attacker doesn't bypass MFA. Instead, they wait for the victim to solve it, then steal the session tokens issued as a result. For more on how these attacks work, see our analysis of phishing and token compromise in SaaS environments.
Microsoft documented widespread AiTM campaigns throughout 2024 and 2025, targeting organizations across industries. These attacks succeed because they exploit the fundamental bearer token problem: valid tokens work regardless of how they were obtained.
Malware & Infostealers
Malware specifically designed to extract tokens from compromised systems has become increasingly prevalent. These infostealers target browser storage where applications cache OAuth tokens, session cookies, and saved credentials.
Modern browsers store authentication tokens in local storage, session storage, and cookie databases to enable seamless user experiences. Malware with appropriate permissions can read these storage locations, exfiltrating tokens to attacker-controlled infrastructure.
Raccoon Stealer, Redline Stealer, and similar malware families specifically target browser token storage. Once deployed on a victim's system, these tools systematically extract saved credentials, cookies, and tokens, then transmit them to command-and-control servers.
The stolen tokens arrive at attacker infrastructure ready to use. No decryption required. No password cracking needed. The tokens work immediately, granting access to whatever resources they authorize.
This attack vector particularly threatens organizations that allow personal devices or implement bring-your-own-device policies. A single compromised personal laptop can expose corporate OAuth tokens, session cookies, and API keys that grant access to enterprise SaaS applications.
Vendor & SaaS Supply Chain Compromise
SaaS supply chain attacks target the integrations and OAuth connections between applications. When attackers compromise a SaaS vendor, they gain access to OAuth tokens the vendor stores for customer integrations, tokens that grant access to customer environments.
The Salesloft-Drift incident demonstrated this attack path clearly. Attackers breached Salesloft's infrastructure and stole OAuth tokens Salesloft had received from customer integrations. Those tokens granted access to customer Salesforce instances, Gainsight deployments, and other connected applications.
The breach affected more than 700 companies because of how OAuth integrations extend trust. Each customer had authorized Salesloft to access their Salesforce data. Salesloft stored the OAuth tokens it received. When attackers compromised Salesloft, they inherited those tokens and the access they granted.
Organizations receiving vendor breach notifications often focus on whether the vendor stored their data. The more critical question: did the vendor store OAuth tokens that grant access to our environment? Those tokens create direct attack paths that bypass perimeter security entirely.
This represents the core challenge of SaaS supply chain security. Trust extends through integration chains, often without visibility into which vendors hold tokens that access your most sensitive applications. Understanding SaaS supply chain risk requires mapping these token-based trust relationships.
Exposed Secrets in Code & Logs
API tokens and keys frequently leak through development and operational processes. Developers commit credentials to code repositories. Applications log API requests including authentication headers. Build pipelines store secrets in configuration files.
The CircleCI incident exposed this vulnerability at scale. Attackers gained access to CircleCI's production environment and exfiltrated customer secrets, including API tokens, encryption keys, and service credentials. Those stolen tokens granted access to customer environments, enabling data theft and further compromise.
Public code repositories present particular risk. GitHub, GitLab, and similar platforms host millions of repositories containing hardcoded credentials. Automated scanning tools constantly search for exposed API keys, immediately testing discovered credentials against target services.
Application logs create another exposure vector. Developers often log full HTTP requests during debugging, inadvertently capturing Authorization headers containing bearer tokens. Those logs persist in log aggregation systems, SIEM platforms, and backup storage, expanding the attack surface for token theft.
The persistence of these exposures compounds the risk. A token committed to a repository three years ago might still grant valid access today if never rotated. The exposure happened once. The vulnerability persists indefinitely until someone discovers and revokes the compromised credential.
Consent Phishing (OAuth Phishing)
Consent phishing tricks users into authorizing malicious OAuth applications. Rather than stealing credentials or tokens, attackers convince victims to grant tokens directly through legitimate OAuth authorization flows.
The attack begins with a phishing email containing a link to an OAuth authorization page. The page appears legitimate because it uses real OAuth protocols, connects to real identity providers, and presents authentic-looking permission requests.
The victim clicks "Authorize," completing whatever MFA challenges their organization requires. This is a legitimate MFA protecting a legitimate OAuth flow. The problem: the application requesting authorization is malicious.
Once authorized, the malicious application receives OAuth tokens granting the permissions the victim approved. Those tokens work exactly as intended because they're not stolen; they're legitimately issued. The victim unknowingly granted an attacker persistent access to their data.
This OAuth attack succeeds because it exploits user trust and the complexity of OAuth scopes. Users see familiar authorization prompts and approve them without carefully reviewing requested permissions. Attackers request broad OAuth scopes granting access to email, files, contacts, and calendar data.
The tokens issued through consent phishing persist until explicitly revoked. Password resets don't help. MFA re-enrollment doesn't help. The OAuth authorization remains valid, granting the attacker continued access through legitimately obtained tokens.
Organizations must monitor OAuth authorizations as carefully as they monitor authentication events. New OAuth grants represent potential security incidents, especially when they request sensitive OAuth scopes or come from unfamiliar applications.
What Attackers Do With Stolen Tokens
Access Data Without Authentication
Stolen tokens grant immediate access to protected resources without requiring authentication. The attacker presents the token. The application validates the token. Access is granted. No password prompt. No MFA challenge. No authentication event logged.
This characteristic makes token theft particularly dangerous. Traditional security monitoring focuses on authentication anomalies such as failed login attempts, unusual locations, impossible travel, and MFA fatigue. Token-based access bypasses authentication entirely, operating in the blind spots of authentication-focused security tools.
The access appears legitimate because the token is legitimate. It was validly issued, properly signed, and hasn't expired. The application has no mechanism to determine whether the entity presenting the token is the entity that originally received it. Bearer tokens work for whoever bears them.
Security teams investigating suspicious activity often check authentication logs first. Token-based access won't appear there. The authentication happened when the token was issued, potentially hours, days, or months earlier. The current access uses that token without re-authenticating.
Maintain Persistent Access
Refresh tokens enable attackers to maintain persistent access even after organizations respond to security incidents. When security teams discover a compromise, standard response procedures include forcing password resets, requiring MFA re-enrollment, and terminating active sessions.
These actions revoke passwords and session tokens. They don't revoke refresh tokens unless explicitly included in the response procedure. The attacker's refresh token continues working, generating new access tokens that grant continued access to the compromised environment.
This persistence challenge affects incident response effectiveness. Organizations believe they've terminated attacker access by resetting credentials and killing sessions. The attacker uses their stolen refresh token to generate a new access token and resumes malicious activity.
The problem extends to OAuth integrations. When a user leaves the organization, IT teams disable their account and revoke their credentials. OAuth tokens the user authorized often remain active, continuing to grant access to applications the departed user connected.
According to Obsidian's analysis, organizations average hundreds of OAuth authorizations from former employees. Each represents a potential access path that survived the deprovisioning process. Attackers who steal these tokens gain access that appears to come from legitimate, previously authorized integrations.
Move Laterally Across Applications
OAuth tokens often grant access beyond the application that issued them. Modern SaaS environments connect through integration chains where one application's access extends to connected applications through inherited permissions.
A stolen OAuth token from a marketing automation platform might grant access to the connected CRM. That CRM token might provide access to the customer support platform. The support platform connects to the data warehouse. One stolen token becomes a pathway across the entire SaaS environment.
This SaaS-to-SaaS lateral movement exploits the trust relationships organizations build through integrations. Each connection extends access, creating chains that attackers follow from initial compromise to high-value targets.
The Salesloft-Drift incident demonstrated this attack path. Stolen tokens granted access to Salesforce. From Salesforce, attackers accessed Gainsight. The integration chains multiplied the impact, extending a single vendor breach to hundreds of downstream organizations.
Traditional network segmentation doesn't prevent this lateral movement. The connections are authorized. The tokens are valid. The access flows through legitimate integration channels. Security tools monitoring network traffic see normal API calls between connected applications.
Organizations must map these trust relationships to understand their blast radius. When a vendor is compromised, which OAuth tokens grant access to your environment? Which applications can those tokens reach through integration chains? The answers define your exposure to supply chain token theft.
Exfiltrate Data at Scale
API tokens enable automated, high-speed data extraction that far exceeds human-driven theft. Attackers using stolen API tokens can programmatically query databases, download file repositories, and export customer records at machine speed.
SaaS-to-SaaS data movement operates 10x faster than human activity. A human attacker manually downloading files might exfiltrate gigabytes per day. An attacker with a stolen API token can automate extraction of terabytes per day, limited only by API rate limits and network bandwidth.
This speed creates detection challenges. By the time security teams notice unusual activity, attackers have already exfiltrated massive datasets. The window between initial compromise and data theft collapses from weeks to hours.
The exfiltration appears legitimate because it uses valid tokens making authorized API calls. Data loss prevention tools monitoring for unauthorized access won't trigger because the access is authorized by the stolen token. The requests follow normal API patterns, blending with legitimate integration traffic.
Organizations implementing AI security across SaaS face additional challenges as AI agents and automation tools create new patterns of high-volume data access. Distinguishing malicious token usage from legitimate AI-driven activity requires behavioral baselines that account for machine identity patterns.
Why Token Theft is Hard to Detect
Token theft evades traditional security monitoring because stolen tokens are valid tokens. The authentication system issued them. They're properly signed. They haven't expired. They grant the exact access they're supposed to grant. The only problem: the wrong entity is using them.
Traditional security tools focus on authentication anomalies. Failed login attempts from unusual locations. Impossible travel between geographic regions. MFA fatigue attacks with repeated push notifications. These signals indicate someone trying to authenticate who shouldn't succeed.
Token-based access generates none of these signals. No authentication attempt occurs because the token proves authentication already happened. No failed logins to detect. No MFA prompts to monitor. No password entry to analyze. The attacker presents a valid token and receives access.
The behavioral baseline for machine activity compounds detection challenges. Human users follow predictable patterns including working hours, typical applications, and consistent locations. Machine identities and API tokens operate 24/7, accessing multiple applications simultaneously, making thousands of API calls per hour.
What's normal for a marketing automation integration? How much data should a business intelligence tool extract daily? When does high-volume API activity indicate compromise versus legitimate automation?
Token usage from unexpected IP addresses might be the only clear signal. If a token typically used from AWS infrastructure in us-east-1 suddenly appears from a residential IP in Eastern Europe, that deviation warrants investigation. But many legitimate scenarios create similar patterns, such as developers testing from home networks, cloud functions migrating between regions, or mobile applications roaming across networks.
ASN deviation provides stronger signals. Autonomous System Numbers identify network operators. A token consistently used from Google Cloud infrastructure suddenly appearing from a hosting provider known for malicious activity indicates potential compromise. But this requires baseline knowledge of normal token usage patterns.
User-Agent attribution offers another detection vector. Tokens used by specific applications generate consistent User-Agent strings. A token that always presents as "Salesforce API Client" suddenly appearing with a generic Python requests library User-Agent suggests unauthorized usage.
These signals require continuous monitoring and behavioral modeling that most organizations lack. Traditional security tools don't track token usage patterns across SaaS applications. Cloud access security brokers see API traffic but lack context about which tokens are authorized and what constitutes normal behavior for each.
The detection gap creates opportunity for attackers. Stolen tokens grant access that security tools struggle to distinguish from legitimate activity. Organizations need behavioral analytics specifically designed for token usage patterns, monitoring that understands normal for each OAuth authorization, API key, and service account. Learn more about detecting lateral movement in token-based attacks.
Token Theft Detection Strategies
Monitor Token Usage Locations
Tracking IP addresses and ASNs where tokens are used establishes geographic and infrastructure baselines for each credential. Tokens typically operate from consistent locations such as cloud provider regions, corporate networks, and specific data centers.
Sudden changes in token usage locations indicate potential compromise. A token that consistently originates from AWS us-west-2 appearing from a residential ISP in another country warrants immediate investigation. The token might be stolen, or legitimate usage patterns might have changed.
ASN tracking provides more reliable signals than IP addresses alone. IP addresses change frequently through DHCP, cloud auto-scaling, and network configuration updates. ASNs identify the network operator, providing stable indicators of infrastructure source.
Flagging tokens used from unexpected geographic regions catches many token theft scenarios. Attackers operating from different countries than the legitimate token user create obvious geographic anomalies. But this approach generates false positives when users travel or organizations expand to new regions.
Combining multiple location signals improves detection accuracy. A token used from a new country, through an unfamiliar ASN, with a different User-Agent than previous usage creates high-confidence compromise indicators. Any single signal might have legitimate explanations. Multiple simultaneous deviations indicate theft.
Behavioral Analytics for Token Activity
Establishing baseline data access patterns for each token enables detection of anomalous usage. Normal token behavior includes typical data volumes, standard API endpoints, consistent access schedules, and expected resource targets.
Alerts trigger when tokens deviate from established patterns: accessing unusual data volumes, calling new API endpoints never used before, operating during off-hours when the associated application typically sits idle, or targeting resources the token has never accessed.
Detecting token replay attacks requires comparing current usage against historical patterns. If a token suddenly appears from different infrastructure than the original authorization, that replay from stolen credentials warrants investigation.
The challenge lies in defining normal for diverse token types. OAuth tokens authorized by users might access data during business hours. Service accounts running automated processes operate 24/7. API keys embedded in applications generate consistent traffic patterns. Each requires different behavioral models.
Machine learning approaches can identify subtle anomalies human analysts might miss. Unusual combinations of accessed resources, slight deviations in request timing, or changes in data filtering parameters might indicate reconnaissance activity by attackers exploring what a stolen token can access.
User-Agent and Client Attribution
Monitoring User-Agent strings associated with token usage detects when tokens are used by different software than expected. Legitimate applications generate consistent User-Agent identifiers such as "Slack-Webhook/1.0", "Salesforce API Client", and "Microsoft Graph API".
When tokens appear with different User-Agents, something changed. The application was updated, the integration was reconfigured, or an attacker is using the stolen token with different tooling. Sudden User-Agent changes warrant investigation.
Attackers using stolen tokens often employ generic HTTP libraries that generate User-Agents like "Python-requests/2.28.1" or "curl/7.68.0". These strings indicate programmatic access rather than the specific application that originally received the token.
Flagging automated tools masquerading as legitimate applications catches many token abuse scenarios. A token issued to a mobile application shouldn't appear with a server-side User-Agent. OAuth tokens granted to web applications shouldn't generate API client User-Agents.
This detection approach requires maintaining User-Agent baselines for each token. The first time a token is used, record its User-Agent. Subsequent usage should match. Deviations indicate configuration changes or potential compromise.
Correlate Across Platforms
Connecting token usage across multiple SaaS applications reveals patterns indicating compromised tokens used for lateral movement. An attacker using a stolen token to access connected applications creates a signature: rapid sequential access across integration chains, unusual data queries spanning multiple platforms, or coordinated exfiltration from related systems.
Cross-platform correlation detects these patterns by mapping relationships between applications and tracking how access flows through integration chains. When a token accesses Salesforce, then immediately queries the connected marketing automation platform, then extracts data from the linked analytics tool, that progression might indicate an attacker following integration paths.
Having a powerful model that correlates these relationships, understanding which applications connect to which others, what data flows between them, and what normal cross-application access patterns look like. Anomalies in these patterns indicate potential compromise.
When token theft is confirmed, blast radius analysis determines exposure scope. Which applications did the stolen token access? What data was queried? Which connected applications might be compromised through integration chains? Mapping the full extent of unauthorized access requires understanding the web of OAuth connections and inherited permissions.
Organizations implementing AI agent security face additional correlation challenges as autonomous agents create complex access patterns across multiple applications. Distinguishing malicious token usage from legitimate AI-driven workflows requires sophisticated behavioral modeling.
Token Theft Prevention Best Practices
Shorten Token Lifespans
Reducing access token validity periods limits the window of opportunity for attackers who steal them. Short-lived access tokens (expiring in minutes rather than hours) minimize the time stolen credentials remain useful.
Setting expiration on refresh tokens prevents indefinite persistence. Refresh tokens that never expire grant attackers permanent access if stolen. Configuring refresh token expiration, even if set to months rather than years, eventually terminates stolen credentials without requiring explicit revocation.
The tradeoff involves user experience and operational overhead. Shorter token lifespans mean more frequent re-authentication or token refresh cycles. Applications must handle token renewal gracefully. Users might experience more authentication prompts.
Organizations must balance security and usability. Access tokens expiring in 5 minutes provide strong security but create operational challenges. Tokens lasting 4 hours offer reasonable security with better user experience. The appropriate lifespan depends on data sensitivity and risk tolerance.
Refresh token security improves dramatically when tokens expire. Even setting a 1-year expiration on refresh tokens ensures stolen credentials eventually become useless, limiting attacker persistence to defined timeframes.
Implement Token Binding
Binding tokens to specific clients or devices makes stolen tokens useless when used from different infrastructure. Token binding cryptographically links tokens to the client that received them, requiring proof of possession beyond presenting the token itself.
When implemented, tokens become non-portable. An attacker who steals a bound token cannot use it from their infrastructure because they lack the cryptographic proof that the token belongs to them. The token only works from the original client.
This approach reduces the value of stolen tokens significantly. The bearer token problem (whoever has the token can use it) is partially mitigated by requiring proof that the presenter is the legitimate holder.
Implementation challenges limit widespread adoption. Token binding requires client-side cryptographic capabilities, protocol support across the authentication chain, and careful key management. Many SaaS applications don't support token binding, and implementing it requires significant engineering effort.
Where available, token binding provides strong protection against token theft. Tokens stolen through phishing, malware, or vendor breaches become unusable from attacker infrastructure, limiting the impact of credential compromise.
Monitor High-Risk Token Events
Tracking new OAuth authorizations closely catches consent phishing and suspicious integration activity. Each new OAuth grant represents a potential security incident, especially when requesting sensitive OAuth scopes or coming from unfamiliar applications.
Alerting on tokens granted broad permissions identifies high-risk authorizations before attackers exploit them. OAuth scopes requesting full mailbox access, complete file system read/write, or administrative privileges warrant immediate review.
Reviewing tokens authorized by privileged users provides additional security. When executives, administrators, or users with access to sensitive data authorize new OAuth applications, those grants deserve scrutiny. Compromising a privileged user's OAuth tokens grants attackers elevated access.
Organizations should implement approval workflows for high-risk OAuth scopes. Rather than allowing users to authorize any application requesting any permissions, require security team review for grants exceeding defined risk thresholds.
This approach balances security and productivity. Low-risk OAuth authorizations with limited scopes can proceed without friction. High-risk grants requiring broad permissions or accessing sensitive data trigger review processes.
Revoke Tokens During Incident Response
Including token revocation in breach response playbooks ensures incident response actually terminates attacker access. Standard procedures that reset passwords and kill sessions leave refresh tokens and OAuth authorizations intact, allowing attackers to maintain persistence.
Revoking refresh tokens, not just access tokens, provides complete termination. Access tokens expire quickly on their own. Refresh tokens persist, generating new access tokens indefinitely. Comprehensive incident response must revoke refresh tokens to prevent attackers from regaining access.
Auditing all tokens authorized by compromised users identifies the full scope of required revocations. When a user account is compromised, every OAuth application they authorized might have been accessed by the attacker. Each authorization must be reviewed and potentially revoked.
This process often reveals surprising token sprawl. Users accumulate dozens of OAuth authorizations over time, including forgotten integrations, abandoned applications, and test environments never decommissioned. Incident response becomes an opportunity to clean up stale tokens and reduce attack surface.
Organizations should document token revocation procedures specific to each major SaaS application. How do you revoke OAuth tokens in Salesforce? What's the process for Microsoft 365? Where are API keys stored in AWS? Incident responders need clear procedures for each platform.
Reduce Token Sprawl
Auditing existing OAuth authorizations regularly identifies stale integrations with unused tokens. Applications authorized years ago might still hold valid tokens granting access to current data, even though the integration is no longer actively used.
Removing stale integrations with unused tokens reduces attack surface. Each unused token represents a potential attack path: a credential that grants access but serves no business purpose. Eliminating these credentials reduces exposure without impacting operations.
Identifying toxic combinations (broad permissions combined with inactive usage) prioritizes remediation efforts. An OAuth integration with full read/write access that hasn't been used in 6 months presents higher risk than an active integration with limited scopes.
Regular OAuth audits should be part of standard security operations, not just incident response. Quarterly reviews of all OAuth authorizations, API keys, and service accounts identify opportunities to revoke unused credentials and tighten permissions on active integrations.
This operational discipline requires tooling that provides visibility into OAuth authorizations across the SaaS environment. Manual spreadsheet tracking doesn't scale. Organizations need automated discovery of OAuth grants, usage monitoring, and risk scoring based on permissions and activity patterns. For broader context on SaaS security best practices, understanding token lifecycle management is essential.
How Obsidian Security Detects Token Theft
Obsidian Security provides behavioral monitoring of OAuth token activity patterns across connected SaaS applications. Rather than relying on authentication monitoring that misses token-based access, Obsidian tracks how tokens are actually used: what data they access, from which infrastructure, and with what patterns.
The platform detects anomalies indicating token theft: tokens used from unusual IP addresses, unexpected data volumes accessed through API calls, and new access patterns that deviate from established baselines. These behavioral signals identify stolen tokens being used maliciously, even though the tokens themselves are valid.
ASN and User-Agent attribution identifies token usage from unexpected infrastructure. When a token consistently used from Salesforce infrastructure suddenly appears from a residential proxy network, Obsidian flags the deviation. When User-Agent strings change from legitimate application identifiers to generic scripting tools, that signal indicates potential compromise.
The Knowledge Graph correlates token activity back to authorizing identities, understanding which user or service account originally granted each OAuth authorization. This correlation enables blast radius analysis. When a user is compromised, Obsidian identifies every token they authorized and monitors those tokens for suspicious usage.
Breach impact analysis addresses supply chain scenarios. When a SaaS vendor announces a breach, Obsidian instantly identifies which OAuth tokens grant that vendor access to your environment. Security teams receive immediate visibility into exposure scope, enabling rapid response before attackers exploit stolen vendor tokens.
Continuous OAuth discovery across all connected SaaS applications provides comprehensive visibility into token sprawl. Organizations see every OAuth authorization, API key, and service account across their SaaS environment, not just what's documented in spreadsheets, but what actually exists in production.
This visibility enables the operational discipline required for effective token security: identifying stale integrations, detecting toxic combinations of broad permissions and inactive usage, and maintaining an accurate inventory of non-human identities that create attack surface.
Obsidian doesn't prevent token theft. That requires securing credential storage, implementing phishing-resistant authentication, and hardening vendor security. Obsidian detects when stolen tokens are used maliciously, providing the behavioral signals that distinguish legitimate token usage from attacker activity.
For organizations experiencing integration blind spots, failed compliance audits, or vendor breach notifications, Obsidian provides visibility into the hidden layer between SaaS applications where tokens quietly extend trust and attackers operate undetected.
Learn more at Obsidian Security.
Organizations must include token revocation in incident response playbooks. When investigating account compromise, password resets alone leave attackers with continued access through stolen refresh tokens and OAuth authorizations. Comprehensive response requires revoking all tokens associated with compromised identities.
The shift from credential theft to token theft represents a fundamental change in the threat landscape. Security teams must adapt their detection strategies, response procedures, and monitoring capabilities to address this evolution. The authentication layer and the authorization layer are not the same. Tokens live in the authorization layer, operating in blind spots where traditional security controls lack visibility.
Next Steps:
- Audit existing OAuth authorizations across your SaaS environment
- Identify stale integrations with broad permissions and inactive usage
- Update incident response playbooks to include token revocation procedures
- Implement behavioral monitoring for token usage patterns
- Map integration chains to understand blast radius from vendor compromises
