In January 2025, the IETF published RFC 9700, updating OAuth security best practices for the first time since 2020. The document doesn't introduce new features. It codifies lessons learned from years of OAuth breaches: Booking.com's open redirect vulnerability, Google's domain inheritance flaw, Microsoft's ongoing battle with consent phishing. Every vulnerability in this RFC represents attacks that succeeded in the wild.
The OAuth vulnerabilities every security team should know aren't theoretical risks buried in academic papers. They're actively exploited attack patterns that drove the Salesloft-Drift breach affecting 700+ organizations, the Allianz Life Salesforce compromise exposing 1.1 million customer records, and countless consent phishing campaigns targeting Microsoft Entra ID environments. These attacks share a common thread: they exploit the gap between how OAuth was designed to work and how organizations actually implement it.
Most security teams believe their SSO and MFA protect them from OAuth attacks. In reality, OAuth tokens function independently of your SSO and MFA. Once an attacker obtains a valid OAuth token through consent phishing, token theft, or third-party compromise, they bypass your authentication controls entirely. The token is the key, and whoever holds it gains access.
Key Takeaways
- OAuth implementation choices create most vulnerabilities - Protocol flexibility enables dangerous misconfigurations that attackers exploit at scale
- Bearer tokens provide no sender validation - Stolen OAuth tokens work from any location, device, or network without reauthentication
- Third-party app compromise extends your attack surface - Every OAuth integration creates a potential entry point one integration away from your core SaaS environment
- Behavioral detection catches what inventory misses - Monitoring token usage patterns reveals exploitation that static configuration reviews cannot detect
- RFC 9700 deprecates insecure flows - Implicit flow and other deprecated patterns remain widely implemented despite known vulnerabilities
Why OAuth Implementations Are Vulnerable
Protocol Flexibility Enables Misconfigurations
OAuth's design philosophy prioritizes flexibility over security defaults. The protocol supports multiple grant types (authorization code, client credentials, device code, refresh token), each with different security properties and appropriate use cases. This flexibility creates implementation challenges that manifest as exploitable vulnerabilities.
Authorization servers that support PKCE without enforcing it allow attackers to manipulate requests and bypass PKCE protections through downgrade attacks. OAuth 2.1 now makes PKCE mandatory for all clients, but legacy implementations persist across enterprise environments. Organizations discover these gaps only after attackers exploit them.
The protocol treats security features as optional enhancements rather than baseline requirements. Token rotation, sender constraining, and scope validation become implementation decisions that vary wildly across applications. Attackers understand which implementations skip which protections.
User Trust Exploited by Design
OAuth consent screens were designed for usability, not security understanding. Users approve permissions they don't comprehend, treating "Read all your email" as equivalent to "Read your profile." This design choice creates the foundation for consent phishing attacks that exploit legitimate authorization flows.
The Storm-1286 campaign demonstrated this vulnerability at scale. Attackers created malicious OAuth apps with legitimate-looking consent screens, phished users to authorize, then used the granted tokens for spam distribution and cryptocurrency mining. The consent mechanism functioned exactly as designed. The vulnerability exists in the trust assumption.
Pre-authorized first-party applications compound this problem. Applications that skip consent screens entirely create blind spots where users never see what permissions were granted. The ConsentFix attack pattern exploits these pre-authorized apps in Microsoft Entra environments, capturing authorization codes within their 10-minute validity window.
Token Security Is Implementation-Dependent
OAuth tokens are bearer tokens by default, functioning like physical keys. Whoever possesses the token gains access, with no mechanism to validate the token holder's identity. This design choice shifts security responsibility to implementation details that vary across every application.
Token storage decisions determine breach impact. Access tokens stored in browser localStorage become accessible to any JavaScript code, turning XSS vulnerabilities into token theft opportunities. Tokens in sessionStorage persist across page reloads. Tokens in URL fragments leak through browser history, referrer headers, and server logs.
Token lifetimes and rotation policies differ by implementation. Some refresh tokens never expire, providing indefinite access that survives password resets and MFA reenrollment. The Salesloft-Drift breach leveraged persistent refresh tokens to maintain access across 700+ organizations for 10 days before detection.
Ten OAuth Vulnerabilities Attackers Exploit
1. Open Redirect Attacks
Mechanism: Attackers manipulate the redirect_uri parameter to send authorization codes to attacker-controlled servers. The authorization server validates the redirect URI against registered patterns, but loose validation enables exploitation.
Real example: The Booking.com vulnerability discovered by Salt Labs in 2023 enabled full account takeover through open redirect exploitation. Attackers registered redirect URIs with wildcards or pattern matching, then crafted malicious authorization requests that passed validation but redirected to attacker infrastructure.
Detection: Monitor for redirect_uri patterns deviating from registered URIs, especially those incorporating URL encoding, path traversal, or subdomain variations.
Mitigation: Implement exact string matching on redirect URIs with no wildcards, patterns, or partial matching. RFC 9700 explicitly requires exact matching to prevent this vulnerability class.
2. Authorization Code Interception
Mechanism: Attackers intercept authorization codes before legitimate clients receive them. Mobile applications using custom URI schemes face critical interception risks when malicious apps register as handlers for the same custom schemes.
Why PKCE prevents it: The code verifier proves the same client that requested the authorization code is exchanging it for tokens. Without PKCE, intercepting the code grants full access.
Detection: Watch for authorization codes exchanged from unexpected origins, user agents, or network locations inconsistent with the registered client.
Mitigation: PKCE mandatory for all public clients per RFC 9700 requirements. For confidential clients, PKCE provides defense-in-depth against code interception attacks.
3. Token Storage Vulnerabilities
Mechanism: Tokens stored in browser localStorage or sessionStorage become accessible to any JavaScript code running in the same origin. XSS vulnerabilities transform into token theft opportunities.
Real example: Common finding in application security assessments across SaaS platforms. Attackers exploit XSS to extract tokens, then replay them from attacker-controlled infrastructure.
Detection: Monitor for token usage from unexpected clients, origins, or user agents inconsistent with legitimate application behavior. Behavioral detection identifies when stolen tokens are replayed.
Mitigation: HttpOnly cookies prevent JavaScript access. Secure flag ensures HTTPS-only transmission. Server-side token management eliminates browser storage entirely. Learn more about better OAuth security for core SaaS applications.
4. Consent Phishing
Mechanism: Attackers create malicious OAuth applications with legitimate-looking consent screens. Users approve permissions believing they're authorizing a trusted application. The attacker receives valid OAuth tokens with user-granted permissions.
Real example: Storm-1286 campaign used OAuth consent phishing for cryptocurrency mining across Microsoft 365 environments. Attackers registered apps with names mimicking legitimate services, then phished users to authorize.
Detection: Monitor for newly authorized OAuth apps, especially those with broad scopes like Mail.ReadWrite, Files.ReadWrite.All, or Directory.ReadWrite.All. Unusual app creation patterns or apps registered to suspicious publishers warrant investigation.
Mitigation: OAuth app governance policies, user awareness training, and app approval workflows that require administrative review before authorization. Discover how to prevent OAuth abuse in your SaaS environment.
5. Refresh Token Persistence
Mechanism: Refresh tokens with no expiration provide indefinite access. Unlike access tokens that expire within hours, refresh tokens can persist for months or years. Attackers who steal refresh tokens maintain access regardless of password changes or MFA reenrollment.
Real example: The Salesloft-Drift breach leveraged persistent refresh tokens across 700+ organizations. Initial compromise in March 2025 established token access that persisted through August, enabling 10 days of active data exfiltration before detection.
Detection: Track refresh token age and usage patterns. Tokens older than organizational policy limits or tokens used from unexpected networks indicate potential compromise.
Mitigation: Token rotation policies that issue new refresh tokens with each use. Appropriate token lifetimes aligned with risk tolerance. Reuse detection that revokes token families when replay is detected.
6. Scope Escalation
Mechanism: Applications request more permissions than initially granted, exploiting flawed server-side scope validation. Some OAuth services allow attackers to "upgrade" stolen or malicious access tokens with extra permissions.
Detection: Monitor for scope changes in existing OAuth connections. Applications that request additional permissions after initial authorization warrant review, especially when scopes expand to sensitive resources.
Mitigation: Server-side scope validation that enforces granted permissions. Incremental authorization only when business requirements justify expanded access. Regular permission audits to identify overprivileged integrations.
7. Implicit Flow Token Exposure
Mechanism: The implicit flow returns access tokens in URL fragments, exposing them in browser history, referrer headers, and server logs. This deprecated flow was designed for JavaScript applications before better alternatives existed.
Why deprecated: RFC 9700 officially deprecates the implicit flow due to inherent token exposure risks. The authorization code flow with PKCE provides equivalent functionality with stronger security.
Detection: Identify applications still using implicit flow through OAuth grant type analysis. Token usage patterns from browser-based applications without authorization code exchange indicate implicit flow.
Mitigation: Migrate to authorization code flow with PKCE. Update client configurations to use recommended grant types. Disable implicit flow support on authorization servers.
8. Token Replay Attacks
Mechanism: Stolen bearer tokens work from any location, device, or network. Attackers replay tokens obtained through phishing, malware, or third-party compromise without triggering authentication challenges.
Detection: Monitor for token usage from new networks, ASNs, or geographies inconsistent with user or application behavior. Sudden changes in access patterns indicate potential token replay. Understanding SaaS-to-SaaS lateral movement helps identify these patterns.
Mitigation: DPoP (Demonstrating Proof-of-Possession) sender constraining that binds tokens to specific clients. Short token lifetimes that limit replay windows. Behavioral monitoring that detects anomalous usage.
9. Third-Party App Compromise
Mechanism: Attackers compromise OAuth applications that hold tokens to your environment. The compromised application's legitimate tokens become attack infrastructure. Every major SaaS supply chain breach follows this pattern.
Real example: The Salesloft-Drift breach demonstrated how a single compromised integration extends across hundreds of customer environments. Attackers accessed Salesloft's GitHub in March 2025, then exploited Drift integration OAuth tokens to access Salesforce instances at 700+ organizations.
Detection: Monitor for behavioral changes in established integrations. Data access volume spikes, unusual resource access, or activity timing inconsistent with automation schedules indicate potential compromise. Explore SaaS backdoors and OAuth integration risks.
Mitigation: Vendor security assessment processes, token permission reviews that enforce least privilege, and behavioral monitoring that detects when trusted integrations behave abnormally.
10. Misconfigured First-Party Apps
Mechanism: Pre-authorized applications with localhost redirect URIs or overly permissive configurations create exploitation opportunities. The ConsentFix attack pattern targets Microsoft Entra environments by exploiting these misconfigurations.
Real example: ConsentFix attacks exploit the legitimate OAuth 2.0 authorization code flow in environments with misconfigured first-party applications. Attackers steal authentication credentials and bearer tokens within the 10-minute authorization code validity window.
Detection: Audit first-party app configurations for dangerous settings like localhost redirects, wildcard redirect URIs, or unnecessary pre-consent grants.
Mitigation: Remove unnecessary pre-consent for first-party applications. Restrict redirect URIs to specific, validated endpoints. Regular configuration reviews to identify and remediate dangerous settings.
Real-World OAuth Attacks: The Pattern That Repeats
Microsoft OAuth Campaigns (Storm-1286)
The Storm-1286 campaign demonstrates the full OAuth attack lifecycle. Attackers began with credential stuffing to gain initial access to compromised accounts. They created malicious OAuth applications with legitimate-looking names and consent screens. Phishing campaigns targeted users to authorize these applications.
Once authorized, the attackers used granted tokens for spam distribution and cryptocurrency mining. The tokens provided persistent access that survived password resets. Detection required identifying the malicious OAuth apps themselves, not just the compromised user accounts.
Google OAuth Domain Takeover
The Google OAuth domain takeover vulnerability revealed how OAuth's trust model extends beyond individual users. When domains expire and are repurchased by attackers, OAuth applications registered to those defunct domains transfer to new owners.
SaaS providers including Slack and Zoom faced critical vulnerabilities where former employees could retain access if providers used email addresses instead of HD (host domain) claims as primary identity. Domain takeover reopened access to corporate resources through inherited OAuth grants. Nudge Security addressed this in December 2023 updates, but the vulnerability pattern persists across the SaaS ecosystem.
Expo CVE-2023-28131
The Expo OAuth proxy vulnerability (CVE-2023-28131) demonstrated how third-party OAuth infrastructure creates single points of failure. Expo provided OAuth proxy services for hundreds of applications. A single vulnerability in this shared infrastructure affected every dependent application.
This pattern repeats across OAuth integration platforms. The Salesloft-Drift breach followed identical mechanics: compromise one integration platform, gain access to hundreds of downstream customer environments. The blast radius extends far beyond the initially compromised system.
Detecting OAuth Attacks in Your Environment
What to Monitor
New OAuth apps authorized warrant immediate investigation, especially those with broad scopes like Mail.ReadWrite, Files.ReadWrite.All, or Directory.ReadWrite.All. Applications registered to unfamiliar publishers or with suspicious naming patterns indicate potential consent phishing.
Token usage from unusual networks or geographies reveals token replay attacks. Legitimate applications and users establish consistent access patterns. Sudden token usage from new ASNs, countries, or cloud providers indicates stolen credentials.
Refresh patterns changing for established integrations signal potential compromise. Applications that typically refresh tokens on predictable schedules suddenly refreshing at unusual times warrant investigation.
Data access patterns deviating from baseline identify exploitation in progress. Integration that typically accesses 100 records daily suddenly downloading 10,000 records indicates data exfiltration.
The Inventory vs. Detection Gap
Most organizations maintain partial OAuth app inventories through manual spreadsheets or point-in-time audits. These inventories answer "which OAuth apps have access" but cannot detect "when those apps behave abnormally."
Inventory shows static configuration. Detection reveals dynamic behavior. An integration with read-only permissions appears safe in inventory. Behavioral detection identifies when that integration attempts write operations, indicating scope escalation or token manipulation.
The gap between inventory and detection explains why organizations discover breaches through vendor notifications rather than internal monitoring. The Salesloft-Drift breach ran for 10 days before Salesloft notified affected customers. Organizations with OAuth inventories but no behavioral detection had no visibility into the active exploitation.
Behavioral Detection Catches What Logs Miss
Traditional log analysis identifies known bad patterns. Behavioral detection identifies deviations from established normal patterns, catching novel attacks that signature-based approaches miss.
Token used from ASN never seen before triggers alerts even when the token itself is legitimate. The anomaly exists in usage context, not token validity.
Data access volume spiking unexpectedly indicates exfiltration attempts. Integration that accessed 50 Salesforce records daily for six months suddenly accessing 5,000 records represents a behavioral anomaly worth investigating.
Integration accessing resources outside normal pattern reveals lateral movement. OAuth app that typically accesses only email suddenly accessing SharePoint files indicates expanded attacker reconnaissance.
Usage timing inconsistent with automation schedules identifies compromised service accounts. Automated integration that runs at 2 AM daily suddenly active at 3 PM suggests token theft and manual attacker activity.
Understanding how to think about SaaS security helps frame these detection challenges in the broader security context.
Know Your OAuth Vulnerabilities Before Attackers Exploit Them
OAuth vulnerabilities exist in your environment right now. Some are misconfigurations you can fix: deprecated implicit flows, missing PKCE enforcement, overprivileged integrations with stale permissions. Others are third-party apps you can't control but can monitor for behavioral anomalies.
The OAuth vulnerabilities every security team should know aren't abstract protocol weaknesses. They're the specific attack patterns that drove the Salesloft-Drift breach, the Google domain takeover, the ConsentFix campaigns. These attacks succeeded because organizations lacked visibility into OAuth token usage and behavioral context to detect exploitation.
Obsidian discovers every OAuth integration across your SaaS environment, identifies risky configurations like missing PKCE or overprivileged scopes, and detects anomalous behavior that indicates active exploitation. The platform correlates token usage patterns with network context, data access volumes, and resource access patterns to identify attacks that log analysis misses.
See which OAuth vulnerabilities pose the greatest risk in your environment. Request a demo to understand your OAuth attack surface before attackers exploit it.
