What are OAuth Tokens? How It Works, and Its Vulnerabilities

Understanding what are OAuth tokens, how it works, and its vulnerabilities has become critical as organizations discover that their biggest SaaS security blind spots exist not inside the applications they manage directly, but in the invisible connections between them. These OAuth tokens function as digital bridges, allowing applications to communicate and share data. Unlike passwords that users actively manage, OAuth tokens operate silently in the background, often with permissions far exceeding what's necessary.

The risk is not theoretical. The Salesloft-Drift breach in late 2025 demonstrated how attackers harvested OAuth tokens from an integration provider to compromise hundreds of customer organizations across Salesforce and Google Workspace. These weren't password attacks. These weren't MFA bypasses in the traditional sense. These were attackers riding trusted connections straight into customer environments, using legitimate tokens that organizations didn't even know existed.

Key Takeaways

• OAuth tokens are bearer credentials that grant application access to your SaaS data without requiring passwords or MFA, functioning like keys that anyone holding them can use
• Refresh tokens persist indefinitely outside your SSO and MFA controls, allowing attackers to maintain access for months or years after initial compromise
• Token theft enables lateral movement across your entire SaaS supply chain, with attackers using one compromised integration to access dozens of connected applications
• Static inventories miss active threats because they show what tokens exist at a point in time, not whether those tokens are being abused right now
• Behavioral detection is essential to identify when legitimate tokens exhibit anomalous usage patterns indicating compromise or misuse

What Are OAuth Tokens?

OAuth tokens are credentials that prove an application has been authorized to access resources on behalf of a user or system. Think of them as the digital bridges between your SaaS applications. When you click "Sign in with Google" or authorize a third-party app to access your Salesforce data, you're creating an OAuth token that allows that application to act on your behalf.

Most SaaS apps implement OAuth tokens as bearer tokens, something like a key. Whoever has this key can use it. This design choice prioritizes convenience over security. Unlike password-based authentication where the server verifies you know a secret, bearer tokens simply require possession. Present the token, gain access. No questions asked.

This fundamental characteristic creates the core vulnerability: if an attacker steals your OAuth token, they don't need your password, they don't need to bypass your MFA, and they don't need to authenticate. They simply replay the token and the service grants access, assuming the request is legitimate.

The Hidden Layer Between SaaS Apps

OAuth tokens represent the hidden layer between your SaaS applications that traditional security tools don't monitor. Your identity provider tracks user logins. Your CASB monitors file sharing. Your SSPM checks configuration settings. But the OAuth tokens connecting Salesforce to your marketing automation platform? The integration tokens allowing your customer success tool to write data into your CRM? Those operate in blind spots where attackers operate without detection.

According to Obsidian's network data, the average enterprise has over 1,000 active OAuth integrations, with many organizations discovering tokens they didn't know existed when they conduct their first comprehensive audit. These aren't just consumer apps like "Connect with Facebook." These are business-critical integrations: data warehouses pulling from production systems, analytics platforms reading customer data, automation tools writing to multiple applications simultaneously.

The Three OAuth Token Types Security Teams Must Understand

Understanding what are OAuth tokens, how it works, and its vulnerabilities requires distinguishing between the three primary token types, each with distinct security implications.

Access Tokens: Short-Lived but Powerful

Access tokens are used to actually access protected resources. When an application needs to read your email, write to your calendar, or pull data from your CRM, it presents an access token to prove authorization.

Key characteristics:

• Typically expire in 15-60 minutes
• Contain or reference the authorized scopes (permissions)
• Used in the Authorization header of API requests
• If stolen, provide limited window of abuse

The short lifespan of access tokens provides some inherent security. An attacker who steals an access token has a narrow window to exploit it before expiration. However, this protection is largely theoretical because access tokens are almost always accompanied by refresh tokens that extend access indefinitely.

Refresh Tokens: The Persistent Threat

Refresh tokens are used to obtain new access tokens without re-authenticating the user. This is where the real security risk lives. Refresh tokens are especially risky because, like service accounts, they operate outside traditional login flows.

Critical security implications:

• Can last months or years without expiration
• Operate independently of your SSO and MFA controls
• Often stored insecurely by third-party applications
• Enable persistent access even after user passwords change
• Rarely monitored by security teams

The Salesloft-Drift breach demonstrated the danger of refresh tokens at scale. Attackers who compromised the integration provider gained access to refresh tokens connecting to hundreds of customer environments. These tokens allowed ongoing access across Salesforce instances, Google Workspace tenants, and other connected applications for weeks before detection. Organizations with comprehensive OAuth token inventories knew they had integrations. Organizations with behavioral detection for SaaS environments identified anomalous token usage within days.

ID Tokens: Identity Claims in Transit

ID tokens contain information about the authenticated user but aren't used for resource access. They're typically JSON Web Tokens (JWTs) containing claims like name, email, and user ID.

Security considerations:

• Not used to access APIs (common misconception)
• Can leak user information if intercepted
• Must be validated to prevent tampering
• Often confused with access tokens by developers

While ID tokens don't directly enable resource access, they can expose sensitive user information and are sometimes incorrectly used for authorization decisions, creating additional vulnerabilities.

How OAuth Tokens Work: The Authorization Flow That Creates Attack Surface

The OAuth authorization flow creates multiple points where security can break down. Understanding what are OAuth tokens, how it works, and its vulnerabilities requires examining each step where trust is established and where that trust can be exploited.

The Standard OAuth Flow

1. User initiates connection to third-party app (clicks "Connect with Google")
2. Identity provider displays consent screen showing requested permissions
3. User approves requested permissions (scopes) without understanding implications
4. Application receives authorization code (short-lived, single-use)
5. Application exchanges code for access + refresh tokens without security team visibility
6. Application uses access token to read/write data as authorized
7. When access token expires, refresh token gets new one without re-consent
8. Repeat steps 6-7 indefinitely with no expiration or re-validation

Where Security Breaks Down

Step 1: Users approve scopes without understanding them. When presented with a consent screen requesting "Read and write access to all files," most users don't consider the implications. They want to complete their task. They click approve. Organizations discovered this problem when conducting OAuth audits and finding integrations with write/delete permissions to production data that were created for one-time testing projects years ago.

Step 2: Tokens issued without security team visibility. The identity provider issues tokens directly to the third-party application. Your security team doesn't receive notification. The tokens don't appear in your identity dashboard. You have no record that this connection was established unless you specifically query for it.

Step 3: Refresh tokens extend access forever without re-consent. Once issued, refresh tokens continue generating new access tokens indefinitely. The user who originally approved the connection might leave the company. The project that required the integration might be cancelled. The third-party vendor might be acquired by a competitor. The refresh token keeps working.

Step 4: No expiration means abandoned integrations stay active. Organizations commonly discover OAuth tokens that have been active for 3-5 years, connecting to applications the current security team doesn't recognize, authorized by employees who no longer work there, with permissions that violate current data governance policies.

The ConsentFix Attack: Exploiting Legitimate Flows

The ConsentFix attack demonstrates how attackers exploit the legitimate OAuth authorization flow. This sophisticated attack against Microsoft Entra ID tricks users into sharing URIs containing authorization codes, then redeems them for bearer tokens within a 10-minute validity window.

Attack sequence:

1. Attacker registers legitimate OAuth application
2. Initiates authorization flow for victim user
3. Tricks victim into sharing the redirect URI (via phishing, social engineering)
4. Extracts authorization code from URI
5. Redeems code for access and refresh tokens before expiration
6. Gains persistent access to victim's resources

This attack succeeds because it uses the legitimate authorization code flow. No vulnerability is exploited. No security control is bypassed. The attack simply manipulates users into sharing authorization codes they don't understand are sensitive credentials.

OAuth Token Formats: What's Inside and Why It Matters

The format of OAuth tokens determines what information they expose and how they can be validated. Understanding token formats is essential for implementing proper OAuth security controls.

JWT (JSON Web Tokens): Self-Contained but Exposed

JWTs are self-contained tokens that include claims about the user and permissions. They consist of three parts: header, payload, and signature, each Base64 encoded and separated by periods.

Security implications:

• Not encrypted by default - anyone can decode and read the payload
• Signature prevents tampering but not reading
• Sensitive data in tokens can be exposed in logs, storage, and transit
• Token size increases with additional claims, affecting performance

Example decoded JWT payload:

{
 "sub": "user@company.com",
 "aud": "third-party-app",
 "scope": "read:email write:calendar",
 "exp": 1735689600
}


This payload reveals the user identity, authorized application, granted permissions, and expiration time. If this token appears in application logs, browser history, or network traffic captures, all this information is exposed.

Opaque Tokens: References Without Information

Opaque tokens are random strings that reference server-side session data. The token itself contains no information. Applications must call an introspection endpoint to validate the token and retrieve associated permissions.

Security advantages:

• No information leakage from token itself
• Immediate revocation when server-side session invalidated
• Smaller token size improves performance in some scenarios

Operational challenges:

• Additional server round-trip required for each validation
• Introspection endpoint becomes critical infrastructure
• Harder to debug without visible claims

Organizations implementing zero trust security for SaaS applications often prefer opaque tokens for high-value integrations despite the operational overhead.

The Security Risks of OAuth Tokens in SaaS Environments

OAuth tokens create specific vulnerabilities in SaaS environments that traditional security controls don't address. These risks compound as organizations adopt more integrations and create increasingly complex SaaS supply chains.

Token Theft Enables SaaS-to-SaaS Lateral Movement

When attackers compromise one application with OAuth integrations, they gain access to stored tokens connecting to other applications. This enables SaaS-to-SaaS lateral movement where the initial breach point becomes a launching pad for accessing the entire SaaS ecosystem.

Attack pattern:

1. Attacker compromises marketing automation platform
2. Finds stored OAuth tokens for Salesforce integration
3. Uses Salesforce tokens to access customer data
4. Discovers additional tokens connecting Salesforce to data warehouse
5. Pivots to data warehouse containing PII from all systems
6. Exfiltrates comprehensive customer database

The Midnight Blizzard attack on Microsoft demonstrated this pattern, where attackers used compromised OAuth applications to access email accounts and then pivoted to other Microsoft 365 services using discovered tokens. Organizations discovered the breach had extended far beyond the initial entry point only after forensic investigation revealed the lateral movement path.

Stale Integrations with Admin Permissions: The Forgotten Attack Surface

Organizations commonly discover OAuth tokens that were created for legitimate business purposes but never deactivated when no longer needed. These stale integrations with admin permissions represent high-value targets that require zero exploitation.

Common scenarios:

• Integration created for one-time data migration project
• Admin scopes granted for initial setup and testing
• Project completes, integration remains active
• Years later: forgotten OAuth app becomes breach entry point

During OAuth audits, organizations routinely find integrations they don't recognize, connecting to vendors they no longer use, with permissions exceeding current data governance policies. One financial services company discovered an OAuth integration with write access to their production Salesforce instance that had been created by a contractor who left the company four years earlier. The integration was still active, still had admin permissions, and connected to a vendor that had been acquired twice since the original authorization.

Third-Party Compromise Becomes Your Compromise

Your vendor gets breached. The attacker finds OAuth tokens connecting to your environment. They ride those trusted connections into your data. You find out when the vendor sends a breach notification-if they send one.

This is the core risk of the SaaS supply chain. Every OAuth integration extends trust to a third party. When that third party is compromised, your data is compromised, even though your security controls were never breached.

The Salesloft-Drift lesson:

• Integration platform compromised
• Attackers accessed stored customer OAuth tokens
• Tokens provided access to Salesforce, Google Workspace, and other connected apps
• Over 700 organizations affected
• Many discovered the breach only after vendor notification

Organizations implementing third-party risk management for SaaS integrations must assume that vendors will be compromised and design controls that limit blast radius when that occurs.

Consent Phishing: Weaponizing the Authorization Flow

Consent phishing attacks weaponize the legitimate OAuth authorization flow. Attackers register OAuth applications with convincing names and descriptions, then phish users to authorize access. No password is stolen, but full data access is granted.

Storm-1286 campaign example:

• Attackers registered OAuth apps mimicking legitimate services
• Phished users to authorize access to email and files
• Used granted permissions for spam distribution and cryptocurrency mining
• Operated for months before detection
• Affected thousands of users across multiple organizations

The attack succeeds because the authorization flow is legitimate. The consent screen is real. The identity provider correctly issues tokens. The only malicious component is the attacker-controlled application receiving those tokens. Traditional phishing defenses don't apply because no credentials are captured. The user voluntarily grants access through the proper channel.

Organizations can detect consent phishing through behavioral monitoring that identifies when newly authorized applications exhibit suspicious behavior patterns.

Over-Scoping: The Governance Failure

Many organizations configure OAuth tokens with excessive permissions. An application needs to read a single calendar, but receives permission to access every organization-wide email. This over-scoping represents a fundamental governance failure that amplifies the impact of every other vulnerability.

Common over-scoping scenarios:

• Requesting "read all files" when only specific folder access needed
• Granting "write" permissions when "read" sufficient
• Authorizing "offline access" (refresh tokens) for short-term integrations
• Providing admin scopes for user-level operations

When over-scoped tokens are stolen, compromised, or abused, the blast radius extends to all data the excessive permissions allow. Organizations conducting OAuth scope audits commonly find that 60-80% of integrations have permissions exceeding operational requirements.

Common OAuth Vulnerabilities Security Teams Must Address

Understanding what are OAuth tokens, how it works, and its vulnerabilities requires examining specific implementation flaws that create exploitable security gaps.

Insecure Token Storage

Access tokens stored in plain text, browser localStorage, or sessionStorage create unauthorized access vulnerabilities. Tokens must be stored in HTTP-only and Secure cookies as the baseline requirement.

Vulnerable storage locations:

• Browser localStorage (accessible to JavaScript, including XSS attacks)
• sessionStorage (same XSS vulnerability as localStorage)
• Plain text in application databases
• Unencrypted configuration files
• Source code repositories (especially refresh tokens)

Organizations should implement API token management practices that encrypt tokens at rest and restrict access to token storage systems.

Credential Leakage Through URLs

Authorization codes and access tokens can leak via browser history and Referer headers when transmitted in URLs. This vulnerability requires prevention through POST requests instead of GET for token exchange and server-side stripping of Referer headers on sensitive endpoints.

Leakage vectors:

• Browser history containing authorization codes in redirect URLs
• Referer headers sending tokens to third-party analytics services
• Server logs recording full request URLs with embedded tokens
• Shared links accidentally containing authorization codes

The upcoming OAuth 2.1 standard addresses this by making PKCE (Proof Key for Code Exchange) mandatory for all implementations, which prevents authorization code interception attacks.

Missing or Weak State Parameter Validation

Failing to include a robust state parameter tied to each user's session enables attackers to conduct CSRF attacks against the authorization flow. The state parameter must be cryptographically random, tied to the user's session, and validated on the redirect.

Attack without state validation:

1. Attacker initiates OAuth flow for victim's account
2. Obtains authorization URL for their own malicious application
3. Tricks victim into clicking authorization URL
4. Victim approves, thinking they're authorizing their own request
5. Authorization code sent to attacker's application
6. Attacker gains access to victim's resources

Proper state parameter implementation prevents this attack by ensuring the authorization response matches the specific request initiated by the user.

Flawed Redirect URI Validation

If the system does not strictly validate redirect URIs, attackers can manipulate authorization flows to direct tokens or codes to endpoints they control. Validation must be byte-for-byte exact match, not substring or pattern matching.

Vulnerable validation examples:

• Allowing any subdomain: https://*.example.com/callback
• Permitting path traversal: https://app.example.com/callback/../attacker-endpoint
• Accepting HTTP alongside HTTPS
• Using regex patterns with bypass opportunities

The ConsentFix attack exploited weak redirect URI validation to steal authorization codes from Microsoft Entra ID. Organizations must implement strict URI validation and regularly audit registered redirect URIs for all OAuth applications.

Insufficient Scope Validation

Attackers can "upgrade" stolen or maliciously-obtained access tokens with extra permissions when OAuth services fail to validate requested scopes against initial authorization requests. The authorization server must verify that requested scopes were actually granted during the authorization flow.

Scope upgrade attack:

1. User authorizes application with "read:profile" scope
2. Application receives access token
3. Application requests new access token with "write:files" scope
4. Authorization server issues upgraded token without re-consent
5. Application gains unauthorized write access

This vulnerability often occurs when authorization servers treat refresh token exchanges as trusted operations that don't require scope validation.

Token Replay Attacks and the Need for Sender-Constrained Tokens

Bearer tokens are vulnerable to replay attacks where stolen tokens are used from different locations, devices, or networks. DPoP (Demonstrating Proof of Possession) and Mutual TLS cryptographically bind tokens to specific clients, preventing token replay attacks.

Traditional bearer token vulnerability:

• Token stolen from legitimate application
• Attacker replays token from their own infrastructure
• Authorization server accepts token (valid signature, not expired)
• Attacker gains access

Sender-constrained token protection:

• Token cryptographically bound to client's public key (DPoP) or TLS certificate (mTLS)
• Attacker steals token
• Attacker attempts replay without corresponding private key
• Authorization server rejects token (can't prove possession)

Organizations protecting high-value integrations should implement sender-constrained tokens despite the additional complexity. This is now recognized as a mandatory technical shift for environments handling sensitive data.

Static Inventory vs. Behavioral Detection: Why Both Matter

Most organizations approaching OAuth security start with the inventory question: "What OAuth tokens exist?" This is necessary but insufficient. The detection question matters more: "Is this token behaving normally?"

What Token Inventory Reveals

A comprehensive OAuth token inventory shows:

• Which applications have been authorized
• What permissions each token grants
• When tokens were created
• Who authorized each integration
• Which tokens haven't been used recently

This information enables basic governance. You can identify stale integrations, revoke over-scoped permissions, and enforce policies requiring periodic re-authorization. Organizations conducting their first OAuth audit commonly discover hundreds of unknown integrations and revoke 30-50% of discovered tokens as unnecessary or excessive.

What Token Inventory Misses

Point-in-time snapshot, outdated immediately. The moment you complete your OAuth inventory, users are authorizing new integrations. Applications are requesting additional permissions. Tokens are being compromised. Your inventory reflects the past, not the present.

Doesn't show how tokens are being used. An inventory tells you a token exists with read access to email. It doesn't tell you the token is downloading 10,000 emails per hour when historical usage was 50 per day. It doesn't reveal the token is accessing data from an IP address in a country where your organization has no operations.

Can't detect when a token is compromised. A stolen token looks identical to a legitimate token in an inventory. Both have the same permissions, same creation date, same authorized application. The difference is behavior, not attributes.

What Behavioral Detection Reveals

Behavioral detection for OAuth tokens identifies anomalies indicating compromise or misuse:

Geographic anomalies:

• Token used from location it has never accessed before
• Simultaneous usage from geographically distant locations
• Access from high-risk countries inconsistent with business operations

Data access pattern anomalies:

• Application accessing data types outside its normal pattern
• Sudden increase in volume of accessed resources
• Access to sensitive data the integration hasn't previously touched

Temporal anomalies:

• Usage timing inconsistent with legitimate automation
• Access during unusual hours for the application's purpose
• Burst activity patterns indicating data exfiltration

Network anomalies:

• Connections from ASNs (Autonomous System Numbers) the token has never used
• User-Agent strings inconsistent with the application's normal client
• API call patterns deviating from established baseline

Organizations implementing behavioral detection for token abuse can identify compromised tokens within hours or days, compared to the industry median detection time of 241 days for traditional breaches.

The Salesloft-Drift Detection Gap

The Salesloft-Drift breach illustrated the difference between inventory and detection. Organizations with OAuth token inventories knew they had Salesloft integrations. They could see the tokens existed and what permissions they granted. But this inventory didn't reveal when those tokens were compromised and used by attackers.

Organizations with behavioral detection identified anomalous token usage quickly:

• Tokens accessing data they had never touched before
• Usage patterns inconsistent with Salesloft's normal operations
• Geographic access from locations outside expected parameters
• Volume of API calls exceeding historical baselines

The difference was weeks of undetected access. Inventory showed what existed. Behavioral detection showed what was happening.

Emerging OAuth Threats: What Security Teams Must Prepare For

The OAuth threat landscape continues evolving as attackers develop new techniques and organizations adopt new technologies that expand the attack surface.

The Google OAuth Vulnerability: Persistent Access After Account Suspension

A newly disclosed Google OAuth vulnerability allows former employees to retain access to corporate resources like Slack and Zoom even after account suspension. This vulnerability demonstrates how OAuth tokens can persist independently of the identity provider's access controls.

Attack scenario:

1. Employee authorizes corporate Slack to access Google account
2. OAuth tokens issued connecting Slack to Google services
3. Employee leaves company, Google account suspended
4. OAuth tokens continue working, providing ongoing access
5. Former employee maintains access to corporate Slack through Google OAuth integration

This vulnerability highlights the need for organizations to inventory and revoke OAuth tokens as part of offboarding procedures, not just disable user accounts.

Agentic AI and Machine Identity Sprawl

By 2026, autonomous AI systems hold their own identities and OAuth tokens, creating machine-to-machine identity governance challenges most organizations have not addressed. These AI agents operate continuously, make autonomous decisions about data access, and create integrations without human oversight.

New risks from AI agents:

• Agents autonomously authorizing new OAuth integrations
• Machine-to-machine tokens with broad permissions
• AI systems accessing data based on inferred need, not explicit authorization
• Lack of human oversight for agent-initiated connections

Agentic AI and Machine Identity Sprawl

By 2026, autonomous AI systems hold their own identities and OAuth tokens, creating machine-to-machine identity governance challenges most organizations have not addressed.[1] These AI agents operate continuously, make autonomous decisions about data access, and create integrations without human oversight.

New risks from AI agents:

• Agents autonomously authorizing new OAuth integrations
• Machine-to-machine tokens with broad permissions
• AI systems accessing data based on inferred need, not explicit authorization
• Lack of human oversight for agent-initiated connections

Organizations must extend OAuth governance to AI agents and implement controls that monitor machine identity behavior patterns.

GNAP: The Successor to OAuth 2.0

The IETF is developing GNAP (Grant Negotiation and Authorization Protocol) as a successor to OAuth 2.0, offering a more transactional, key-bound model that addresses architectural flaws of its predecessor.[1]

GNAP improvements:

• Native support for sender-constrained tokens
• Transactional model reducing state management complexity
• Better support for non-browser clients
• Improved security properties by default

Security teams should monitor GNAP development and plan migration strategies as the protocol matures and gains adoption.

Securing OAuth Tokens: Controls Security Teams Must Implement

Addressing what are OAuth tokens, how it works, and its vulnerabilities requires implementing multiple layers of controls spanning governance, technical controls, and behavioral monitoring.

Implement Comprehensive OAuth Token Discovery

You cannot secure what you cannot see. The first step is discovering every OAuth token across your SaaS environment:

Discovery requirements:

• Automated scanning of all SaaS applications
• Identification of both user-authorized and service account tokens
• Mapping of token permissions and scopes
• Documentation of token creation dates and authorizing users
• Tracking of token usage patterns and last access times

Organizations should implement continuous discovery, not point-in-time audits, to maintain current visibility as users authorize new integrations.

Enforce Least Privilege for OAuth Scopes

Every OAuth token should have the minimum permissions required for its legitimate purpose:

Scope governance practices:

• Review and approve requested scopes before authorization
• Reject requests for excessive permissions
• Implement policies requiring justification for sensitive scopes
• Regularly audit existing tokens for over-scoped permissions
• Revoke unnecessary permissions from active tokens

Organizations commonly find that 60-80% of OAuth integrations can operate with reduced permissions after proper scope review.

Mandate Token Expiration and Periodic Re-Authorization

Refresh tokens that persist indefinitely create unlimited windows for compromise. Organizations should:

Expiration policies:

• Set maximum lifetime for refresh tokens (90-180 days recommended)
• Require periodic re-authorization for sensitive integrations
• Implement automated revocation of unused tokens
• Force re-consent when applications request additional permissions
• Revoke all tokens during user offboarding

These policies ensure that OAuth access remains aligned with current business needs and employment status.

Implement Behavioral Monitoring for Token Abuse

Static controls are necessary but insufficient. Organizations must monitor OAuth token behavior to detect compromise and misuse:

Behavioral monitoring capabilities:

• Geographic anomaly detection for token usage
• Data access pattern analysis
• Volume and velocity monitoring
• Network attribution (ASN, IP, User-Agent)
• Correlation with user behavior and business context

Obsidian's Knowledge Graph approach correlates OAuth token behavior with the changing relationships between SaaS applications, users, and data to identify toxic combinations and anomalous usage patterns that indicate compromise.