Inside OAuth Exploitation: How Attackers Chain Misconfigurations to Compromise Enterprise SSO .
Technical analysis of OAuth and SAML exploitation techniques used in 2026 breaches. Learn how attackers chain misconfigurations for SSO compromise and how penetration testing reveals defensive gaps.
Published
Feb 15, 2026
Category
Technical Deep Dive
Author
Aleksandr Ivanov
In mid-January 2026, the ShinyHunters threat cluster executed a coordinated campaign that compromised Match Group's Okta SSO environment, exfiltrating over 10 million records from Hinge, OkCupid, and Match.com. The attack vector wasn't a zero-day vulnerability or sophisticated malware. Instead, attackers exploited the trust model inherent to OAuth 2.0 through a technique called ConsentFix, a social engineering approach that weaponizes legitimate authentication flows to harvest privileged access tokens.
This incident represents a broader pattern security teams are encountering. Enterprise SSO implementations based on OAuth and SAML protocols are being systematically compromised not through protocol flaws, but through the exploitation of implementation gaps, parser inconsistencies, and the inherent trust relationships these systems create. Understanding how attackers chain these misconfigurations into full authentication bypass requires examining the actual exploitation mechanics, not just theoretical attack surfaces.
The OAuth Trust Model and Its Exploitation Surface
OAuth 2.0 operates on a delegation model where an authorization server issues bearer tokens that grant access to protected resources. The critical security assumption is that whoever possesses a valid token has legitimate access, the protocol provides no inherent sender validation mechanism. This design choice, documented in IETF RFC 9700, creates an exploitable condition: stolen tokens function identically to legitimate ones, regardless of origin, device, or network location.
Mandiant's analysis of the January 2026 ShinyHunters campaign reveals how attackers leverage this trust model. The attack flow follows a predictable pattern:
Initial access begins with vishing, voice phishing where attackers impersonate IT support staff and contact employees directly. During these calls, targets are directed to credential harvesting sites mimicking their organization's SSO portal. For the Match Group breach, the phishing domain was matchinternal[.]com, registered specifically to exploit visual trust. These sites don't need to bypass security controls; they simply collect credentials through voluntary submission.
Token acquisition occurs when victims authenticate against the harvesting site. Using tools like SquarePhish2, attackers initiate legitimate OAuth Device Authorization Grant flows with pre-configured client IDs. The victim receives an authentic device code from Microsoft's infrastructure, not a phishing simulation, but actual Microsoft authentication prompts. When the victim enters this code while still on the call with the attacker, the authentication completes and Microsoft's token endpoint issues valid OAuth tokens directly to the attacker's infrastructure.
Persistence establishment happens through OAuth application abuse. Once attackers obtain initial access, they register malicious OAuth applications or add credentials to existing line-of-business applications. Microsoft Security's research documents how the Storm-1283 threat actor created applications with names mimicking legitimate Microsoft Entra services. These applications request broad permission scopes - Mail.Read, Files.ReadWrite.All, Sites.ReadWrite.All, which victims approve without understanding the implications. Once consent is granted, the application receives refresh tokens that enable continuous access token generation without further authentication prompts.
ConsentFix: Weaponizing the Authorization Code Flow
The ConsentFix technique, disclosed by PushSecurity in January 2026, demonstrates how attackers exploit the authorization code flow's design to bypass Conditional Access policies and device compliance checks. The attack chain proceeds as follows:
Attackers generate a malicious Microsoft Entra login URI targeting the "Microsoft Azure CLI" client application and "Azure Resource Manager" resource. This URI is delivered through compromised websites or phishing emails. When victims visit the malicious site, they're redirected to Microsoft's legitimate authentication page, there's no phishing detection to trigger because the authentication infrastructure is genuine.
After the victim completes authentication, Microsoft's authorization server generates an authorization code and redirects the browser back to the redirect_uri specified in the initial request. Here's where the exploitation occurs: the authorization code appears in the URL, visible to the attacker-controlled page. The attacker extracts this code and immediately exchanges it at Microsoft's token endpoint for access tokens.
The critical security bypass happens because Microsoft Entra's Conditional Access policies evaluate at authentication time, not at token exchange. The victim's browser satisfies device compliance requirements during authentication, but when the attacker exchanges the authorization code from their infrastructure, no re-evaluation occurs. The token endpoint validates only that the code is legitimate and unexpired, it cannot determine that a different party is redeeming it.
Detection of ConsentFix attacks requires analyzing Azure sign-in logs for a specific pattern: two authentication events from the same session, one interactive sign-in from the victim's location, followed immediately by a non-interactive sign-in from a different network as the attacker redeems the stolen code. Security teams should monitor for temporal proximity between these events, as the window between code generation and redemption is typically seconds.
SAML Parser Differentials and Authentication Bypass
While OAuth exploitation relies primarily on social engineering and misconfiguration, SAML vulnerabilities enable direct authentication bypass through exploitation of XML parsing inconsistencies. PortSwigger's December 2025 research demonstrates how attackers achieve full authentication bypass in Ruby and PHP SAML ecosystems through void canonicalization attacks, a technique that exploits parser-level inconsistencies to bypass XML signature validation while presenting valid SAML documents to applications.
The fundamental vulnerability exists because SAML libraries often parse XML documents multiple times using different parsers. Ruby-SAML, for example, uses REXML to validate signatures and Nokogiri to extract attributes. When these parsers interpret the same XML document differently, attackers can craft malicious assertions that pass signature verification but are processed as different data by the application.
The void canonicalization attack works by exploiting how XML parsers handle the SYSTEM identifier in Document Type Declarations. During initial parsing, one assertion structure is validated. During re-parsing with a different library, the XML syntax changes due to quote normalization, causing XML comments to be processed differently and revealing an entirely different assertion structure, one controlled by the attacker.
The GitLab Enterprise 17.8.4 exploit combined void canonicalization with namespace confusion to achieve unauthenticated access. Attackers repurposed legitimate signed WS-Federation metadata XML, manipulated it to inject forged assertions, then bypassed email domain access controls through parser discrepancies. The application validated the signature against the original structure but processed attributes from the attacker's injected structure.
Fortinet products faced similar SAML exploitation through CVE-2026-24858, where attackers crafted SAML response messages that bypassed FortiCloud SSO authentication. The vulnerability, actively exploited in the wild during January 2026, allowed attackers with FortiCloud accounts to authenticate to devices registered to other organizations. Arctic Wolf observed that patched devices remained vulnerable because the underlying SAML signature verification mechanism accepted attacker-crafted assertions that should have failed validation.
Chaining OAuth Flows for Lateral Movement
Once attackers obtain initial OAuth tokens, lateral movement across SaaS environments follows predictable patterns that exploit the interconnected nature of modern cloud infrastructures. The ShinyHunters campaign demonstrates this methodology clearly: after compromising Okta SSO credentials, attackers systematically targeted Microsoft 365, Google Workspace, Salesforce, and DocuSign environments, using the initial access to pivot through OAuth-integrated applications.
Google's threat intelligence analysis documents specific techniques used by UNC6661 and UNC6671 clusters. After establishing access to Microsoft 365, attackers used PowerShell to download data from SharePoint and OneDrive. The user-agent string in audit logs, PowerShell reveals this technique, yet organizations rarely alert on scripted access patterns that fall within granted OAuth scopes.
The privilege escalation vector involves OAuth scope abuse. Many organizations configure OAuth applications with excessive permissions for operational convenience, granting Mail.Read when only Mail.ReadBasic is needed, or Files.ReadWrite.All when Files.Read.Shared would suffice. Once attackers control an OAuth application, they can request any scope the application is configured to support, and if users have previously consented, no additional approval is required.
Attackers also abuse Google Workspace add-ons for operational security. In at least one ShinyHunters intrusion, attackers enabled the ToogleBox Recall add-on, a tool designed to search for and permanently delete emails. By authorizing this add-on through the compromised OAuth session, attackers systematically removed forensic evidence of their data exfiltration activities, searching for keywords like "security incident," "audit," and "breach" to identify and delete detection-relevant communications.
Authorization Code Interception Without PKCE
The authorization code grant type remains the most secure OAuth flow when properly implemented, but the absence of Proof Key for Code Exchange (PKCE) creates exploitable interception opportunities. PKCE, mandated by RFC 9700 for all public clients, prevents authorization code theft by requiring the same client that requested the code to exchange it for tokens.
Without PKCE, attackers can intercept authorization codes through several vectors. Mobile applications using custom URI schemes face critical risks when malicious applications register as handlers for the same scheme. If a legitimate app uses myapp://callback as its redirect URI, an attacker's app can register the same scheme. When the authorization server redirects the browser with the authorization code, the malicious app receives it instead.
Network-level interception represents another attack path. Authorization codes transmitted over unencrypted HTTP connections or through improperly configured proxies can be captured by man-in-the-middle attackers. Even with HTTPS, TLS inspection appliances used by enterprises may inadvertently expose codes to security infrastructure that lacks proper access controls.
The exploitation impact extends beyond immediate account compromise. Intercepted authorization codes enable attackers to obtain refresh tokens, which persist beyond the original session and can be used to generate new access tokens indefinitely. Organizations often configure refresh token lifetimes measured in months or years for user convenience, creating a persistent compromise window from a single interception event.
Detection of authorization code interception requires monitoring for codes exchanged from unexpected origins, user agents, or network locations inconsistent with the registered client. However, this presumes comprehensive logging of token endpoint requests, a practice many organizations fail to implement. The MITRE ATT&CK framework categorizes these techniques under T1528 (Steal Application Access Token), yet detection guidance remains limited to monitoring for "unusual access patterns", unhelpfully vague for security operations teams seeking actionable detection logic.
Token Persistence and Post-Compromise Operations
OAuth token persistence mechanisms explain why attackers maintain access long after initial compromise and credential resets. Refresh tokens are the primary persistence mechanism, they enable continuous access token generation without reauthentication. Unlike access tokens, which expire in minutes or hours, refresh tokens persist for extended periods and survive password changes.
The token hierarchy creates layered persistence. At the base level, attackers maintain refresh tokens. These generate access tokens on demand. When access tokens expire, the refresh token automatically obtains new ones without triggering authentication events. This makes token-based access invisible to authentication monitoring that alerts on password use or MFA challenges.
Behavioral anomalies provide detection signals for token abuse. Legitimate OAuth tokens typically exhibit consistent geographic access patterns, predictable refresh intervals, and scope usage aligned with user behavior. Compromised tokens show divergent patterns: geographic jumps that exceed physically possible travel times, refresh frequency spikes indicating scripted access, and sudden utilization of previously unused scopes.
Microsoft Entra ID's Continuous Access Evaluation (CAE) addresses some token persistence issues by re-evaluating active sessions against Conditional Access policies in near real-time. When critical events occur, user location changes, IP address shifts, or risk level increases, CAE triggers immediate policy checks during token use rather than waiting for token expiry. However, CAE adoption remains limited, and many organizations continue relying on static token expiration as their sole mitigation.
The ultimate persistence technique involves OAuth application registration. Once attackers register a malicious OAuth application in the victim's tenant, they can request user consent through any compromised account. If granted, the application receives its own OAuth credentials, client ID and secret, plus refresh tokens for the consenting user. Even if the organization revokes all user sessions and forces password resets, the OAuth application persists until explicitly removed from the tenant's application registration list.
Defensive Gaps in Production Environments
The disparity between secure OAuth/SAML implementation requirements and production reality creates persistent exploitation opportunities. Organizations implement SSO assuming it improves security, yet the centralized authentication model introduces single points of failure when underlying configurations are weak.
The most common gap is missing PKCE enforcement. Despite RFC 9700's mandate for all OAuth clients, many enterprises deploy public clients without PKCE because it wasn't required in earlier specifications. Organizations that implemented OAuth before 2021 often lack PKCE, and the operational complexity of modifying production authentication flows means these vulnerable implementations persist indefinitely.
Redirect URI validation failures represent another widespread vulnerability. The Booking.com exploit, discovered by Salt Labs in 2023, demonstrated how open redirect vulnerabilities combined with wildcard redirect URI patterns enable full account takeover. Organizations configure redirect URIs with patterns like https://*.company.com/callback for deployment flexibility, but this accepts redirects to any subdomain, including attacker-controlled subdomains if the organization's DNS or subdomain registration processes are compromised.
SAML implementations suffer from XML security library misuse. Organizations treating SAML as "configuration work" rather than security-critical code deployment fail to recognize that XML parsing and signature validation require rigorous security review. The Ruby-SAML vulnerabilities affecting versions prior to 1.18.0 existed for years before discovery because signature validation logic appeared to work correctly in normal use, only specialized security testing revealed the parser differential vulnerabilities.
Monitoring gaps compound implementation weaknesses. Most organizations log authentication events but fail to capture token lifecycle events comprehensively. OAuth refresh token usage, scope changes, new application consent, and token endpoint access from unexpected networks often generate no alerts. When compromise occurs, security teams lack the telemetry to trace the attack path or determine the scope of data access.
What Principle Breach Observes in Real Testing
During penetration testing engagements, we consistently find organizations have implemented OAuth and SAML SSO but haven't validated the security assumptions these protocols depend on. The testing methodology reveals where theoretical security breaks down against practical attack scenarios.
SAML testing involves fuzzing SAML responses to identify parser differential vulnerabilities. We take legitimate signed assertions, manipulate them using techniques from PortSwigger's research, and replay them to the service provider. Organizations using Ruby-SAML, PHP-SAML, or custom XML parsing frequently accept manipulated assertions that should fail signature validation. The root cause is invariably the same: multiple parsers handling the same document with different interpretation logic.
Device code phishing simulations test organizational resilience to social engineering attacks targeting SSO. We call employees claiming to be from IT support, guide them through "MFA enrollment updates," and direct them to internal-looking authentication portals. The success rate exceeds 40% even in organizations with security awareness training, because the authentication pages are legitimately Microsoft or Google infrastructure, employees see familiar login prompts and trust the process.
We also examine OAuth application consent patterns. Organizations rarely audit existing OAuth application permissions or review new application registrations. We've discovered third-party applications with permissions to read all email, access all SharePoint files, and manage all users, permissions requested during initial setup and never reviewed again. When these third-party vendors suffer breaches, the OAuth tokens they hold provide attackers with immediate access to customer environments.
Actionable Detection and Mitigation
Defending against OAuth and SAML exploitation requires moving beyond configuration checklists to behavioral monitoring and continuous validation. Organizations need detection capabilities that identify exploitation patterns, not just implementation gaps.
For OAuth environments, implement comprehensive token lifecycle monitoring. Log every token issuance event including client ID, requested scopes, grant type used, and source IP. Monitor for refresh token usage patterns that deviate from established baselines, unusual geographic origins, refresh frequency spikes, or scope changes. Alert on new OAuth application registrations and consent events in near real-time, particularly for applications requesting high-privilege scopes like Mail.Read or Files.ReadWrite.All.
SAML implementations require signature validation hardening. Use a single, well-tested XML parsing library for both signature verification and attribute extraction. Avoid parser mixing that creates differential interpretation risks. Implement strict canonicalization, rejecting any SAML response that contains DTDs, external entities, or unexpected XML constructs. Test SAML handling with malformed responses using tools like SAML Raider to verify rejection of manipulated assertions.
Deploy phishing-resistant MFA using FIDO2/WebAuthn rather than push notifications or SMS codes. Device code phishing and ConsentFix attacks bypass traditional MFA because attackers relay authentication in real-time. FIDO2 binds authentication to specific origin domains, preventing relay attacks since the cryptographic assertion includes the domain being authenticated to. An attacker-controlled proxy cannot replicate valid FIDO2 assertions for the legitimate service.
Enforce PKCE for all OAuth clients without exception. Organizations operating public clients - mobile apps, single-page applications, native desktop applications, must mandate PKCE. For confidential clients, PKCE provides defense-in-depth against code interception. Modern OAuth libraries support PKCE by default; organizations must verify configuration enforces it rather than merely supporting it.
Implement exact string matching for redirect URIs with no wildcards, patterns, or partial matching. Each registered OAuth client should specify complete, fully-qualified redirect URIs. During authorization, validate the redirect_uri parameter against registered values using exact string comparison. This prevents attackers from exploiting open redirects or subdomain vulnerabilities to redirect authorization codes to malicious endpoints.
