SSO Bypass: How Attackers Circumvent Single Sign-On

In December 2020, security teams at FireEye noticed something strange: authenticated access to customer environments from infrastructure they didn't recognize. The attackers hadn't stolen passwords. They hadn't bypassed MFA. They had forged SAML tokens that looked identical to legitimate ones. The technique, now known as Golden SAML, meant attackers could authenticate as anyone, to any application, without ever touching the identity provider's authentication flow. SSO had become the attack vector.

Single sign-on systems serve as the master key to enterprise applications. When implemented correctly, SSO streamlines access, strengthens security posture, and simplifies identity management. But this centralization creates a paradox: the same mechanism that protects dozens of applications becomes the single point of failure that, when compromised, grants attackers access to everything behind it.

Key Takeaways

• SSO bypass attacks circumvent authentication entirely, allowing attackers to access applications without valid credentials or MFA challenges
• Golden SAML attacks forge cryptographically valid tokens that identity providers cannot distinguish from legitimate authentication events
• Eight primary attack techniques target different components of the SSO trust chain, from signature validation to session management
• Detection requires behavioral analysis because bypassed authentication produces no failed login attempts or suspicious authentication logs
• Recent vulnerabilities (CVE-2025-47949, CVE-2025-59718/19) demonstrate that even patched systems remain vulnerable to novel bypass techniques

What is SSO Bypass?

SSO bypass refers to techniques that allow attackers to circumvent single sign-on authentication mechanisms and gain unauthorized access to protected applications. Unlike credential theft or brute-force attacks, SSO bypass exploits weaknesses in the authentication protocol itself, the trust relationships between identity providers and service providers, or implementation flaws in how applications validate authentication assertions.

Why Attackers Target SSO

Attackers focus on SSO for one compelling reason: efficiency. A single successful bypass grants access to every application connected to that identity provider. Instead of compromising ten different applications individually, attackers compromise the authentication mechanism once and inherit access to everything.

The mathematics of SSO bypass are brutal. Organizations typically connect 15-50 applications to their SSO provider. One forged SAML token means one attack yields access to all of them. This force multiplication makes SSO bypass attacks particularly attractive to sophisticated threat actors conducting lateral movement campaigns.

The Centralization Trade-Off

SSO creates a fundamental security paradox. Centralizing authentication strengthens security by enforcing consistent policies, enabling MFA, and providing unified logging. But this same centralization concentrates risk. When the central authentication mechanism fails, everything behind it becomes accessible simultaneously.

Most organizations accept this trade-off because the security benefits outweigh the concentrated risk-assuming the SSO implementation is secure. The problem emerges when organizations implement SSO without understanding the attack surface they've created or the behavioral detection capabilities needed to identify compromised sessions.

How Single Sign-On Works (The Attack Surface)

Understanding SSO bypass requires understanding the trust chain that attackers exploit. Modern SSO implementations typically use SAML, OAuth, or OpenID Connect protocols. Each creates specific attack surfaces.

The SAML Authentication Flow

In a SAML implementation:

1. User requests access to a service provider (SP) application
2. SP redirects the user to the identity provider (IdP)
3. IdP authenticates the user (username/password, MFA)
4. IdP generates a SAML assertion containing user identity and attributes
5. IdP signs the assertion with its private key
6. User's browser delivers the signed assertion to the SP
7. SP validates the signature using the IdP's public key
8. SP grants access based on the assertion's contents

Attackers can exploit vulnerabilities at every step of this flow. The signature validation in step 7 represents the critical security control-if attackers can bypass it, forge it, or trick the SP into accepting an invalid assertion, authentication fails completely.

OAuth and OIDC Trust Relationships

OAuth and OpenID Connect implementations create different attack surfaces. Instead of SAML assertions, these protocols use access tokens and refresh tokens. The trust relationship depends on:

• Token validation at the resource server
• Proper scope enforcement limiting token permissions
• Secure token storage preventing theft
• Token lifetime management minimizing replay windows

As detailed in our analysis of OAuth token abuse, attackers increasingly target these tokens because they function as bearer tokens-whoever possesses the token can use it, regardless of how they obtained it.

Where Vulnerabilities Exist

SSO vulnerabilities typically emerge in three areas:

1. Protocol implementation flaws: Improper signature validation, missing audience checks, weak token validation
2. Configuration mistakes: Overly permissive trust relationships, disabled security controls, legacy protocol support
3. Operational gaps: Local authentication fallbacks, shadow IT bypassing SSO, forgotten emergency access accounts

Eight SSO Bypass Attack Techniques

1. Golden SAML Attacks

Golden SAML represents the most devastating SSO bypass technique. Attackers who obtain the SAML signing certificate from the identity provider can forge SAML assertions for any user, to any application, with any permissions-and these forged assertions are cryptographically indistinguishable from legitimate ones.

How It Works

The attack requires three steps:

1. Compromise the IdP and extract the SAML signing certificate and private key
2. Forge SAML assertions for target users and applications
3. Present forged assertions to service providers, which validate successfully

The SolarWinds attack demonstrated this technique at scale. After compromising networks through the supply chain breach, attackers extracted SAML signing certificates from on-premises Active Directory Federation Services (ADFS) servers. They then forged tokens to access Microsoft 365, Azure AD, and other cloud applications without ever authenticating through the actual identity provider.

Why It's Devastating

Golden SAML attacks produce zero authentication events at the identity provider. The IdP never sees the forged authentication because the attacker bypassed it entirely. Traditional security monitoring focused on failed logins, impossible travel, or MFA failures detects nothing. The authentication appears completely legitimate to the service provider.

Detection Requirements

Detecting Golden SAML requires focusing on what happens after authentication, not the authentication event itself. Behavioral detection identifies:

• Users accessing applications they've never used before
• Session behavior inconsistent with user's historical patterns
• Geographic impossibilities (user authenticated from two continents simultaneously)
• Lateral movement patterns following SSO authentication
• Bulk data access immediately after session establishment

2. SAML Signature Bypass

SAML signature bypass exploits improper signature validation in service providers. Instead of forging the signature (which requires the private key), attackers manipulate the SAML assertion in ways that cause the service provider to skip validation or validate the wrong content.

Recent Vulnerabilities

CVE-2025-47949 in the Samlify library demonstrated this attack class. The vulnerability allowed attackers to bypass signature validation entirely through carefully crafted SAML assertions. Applications using vulnerable versions of Samlify accepted unsigned or improperly signed assertions as valid.

CVE-2024-45409 in ruby-saml exploited parser differential attacks. The XML parser used for signature validation processed the assertion differently than the parser extracting user attributes. Attackers crafted assertions that validated correctly but contained different identity information than what the application ultimately processed.

Common Implementation Mistakes

Service providers frequently make these signature validation errors:

• Optional signature validation: Making signature checks optional or allowing unsigned assertions
• Signature not required: Failing to enforce signature presence
• Weak signature algorithms: Accepting deprecated algorithms (SHA-1, RSA-1024)
• Missing certificate validation: Validating signature without verifying the signing certificate

3. XML Injection / Signature Wrapping

XML signature wrapping attacks manipulate the structure of SAML assertions to trick service providers into validating one piece of content while processing a different piece for authentication decisions.

Attack Mechanism

SAML assertions are XML documents with digital signatures. The signature covers specific elements of the document. Attackers can:

1. Insert malicious content outside the signed portion
2. Move the signature reference to point to benign content
3. Duplicate elements causing validation and processing to examine different data

The service provider validates the signature successfully (because the signed content is legitimate) but processes the attacker's injected content for authentication.

Variants and Evolution

Security researchers have documented dozens of XML signature wrapping variants. Each exploits subtle differences in how XML parsers handle:

• Element ordering: Processing first vs. last element when duplicates exist
• Namespace handling: Different parsers resolving namespaces differently
• Comment injection: Using XML comments to hide malicious content
• External entity references: Pointing to attacker-controlled content

4. Token Replay Attacks

Token replay attacks capture valid authentication tokens and reuse them within their validity window. Unlike forgery attacks, replayed tokens are completely legitimate-they were issued by the identity provider and are cryptographically valid.

Attack Vectors

Attackers obtain tokens through:

• Session hijacking: Stealing session cookies via malware or network interception
• Man-in-the-middle attacks: Intercepting tokens during transmission
• Browser exploitation: Extracting tokens from browser storage
• Phishing proxies: Capturing tokens during adversary-in-the-middle (AiTM) attacks

Our detailed analysis of pass-the-cookie attacks demonstrates how attackers steal and replay session tokens to bypass MFA entirely.

Prevention Measures

Preventing token replay requires:

• Strict token lifetimes: Minimizing the replay window
• One-time use enforcement: Invalidating tokens after first use
• Replay detection: Tracking token usage and identifying duplicates
• Device binding: Tying tokens to specific devices or network contexts

5. Local Authentication Fallback Exploitation

Many applications maintain "emergency" local authentication mechanisms alongside SSO. These fallbacks, intended for break-glass scenarios when SSO is unavailable, often become permanent backdoors that bypass SSO entirely.

Common Fallback Patterns

Organizations create local authentication through:

• Direct login URLs: Hidden endpoints accepting username/password
• Administrative accounts: Local admin accounts for emergency access
• Legacy protocol support: IMAP, POP3, or SMTP authentication bypassing SSO
• API keys: Service accounts with permanent credentials

Attackers discover these fallbacks through:

• Documentation review: Finding emergency procedures in public documentation
• Endpoint enumeration: Scanning for /admin, /local-login, /emergency-access paths
• Legacy protocol testing: Attempting IMAP/POP3 connections
• Configuration file analysis: Finding hardcoded credentials in exposed configs

Elimination Strategies

Security teams must:

1. Inventory all authentication paths to each application
2. Disable unused protocols (IMAP, POP3, legacy APIs)
3. Remove local accounts or enforce SSO even for administrators
4. Document and monitor any required emergency access
5. Implement break-glass procedures that generate alerts and require approval

6. SSO Provider Compromise

Attacking the identity provider directly represents the most straightforward SSO bypass: if you control the IdP, you can issue legitimate tokens for any user.

Attack Patterns

IdP compromise occurs through:

• Administrative account takeover: Compromising IdP admin credentials
• Help desk social engineering: Tricking support into resetting admin passwords
• Vendor compromise: Exploiting vulnerabilities in the IdP software itself
• Supply chain attacks: Compromising IdP infrastructure or dependencies

The MGM breach (2023) demonstrated help desk social engineering. Attackers called Okta support, impersonated an IT administrator, and convinced support to reset credentials, granting administrative access to the entire identity infrastructure.

Cascading Impact

IdP compromise creates cascading failures across the entire application ecosystem. With administrative access, attackers can:

• Issue tokens for any user
• Modify authentication policies
• Disable MFA requirements
• Create persistent backdoor accounts
• Export user databases and credentials

7. Misconfiguration Exploitation

SSO misconfigurations create authentication bypasses without requiring exploitation of vulnerabilities. Common misconfigurations include:

Trusted IP Exemptions

Organizations frequently configure "trusted" IP ranges that bypass authentication requirements. Attackers who gain access to these networks (through VPN compromise, network intrusion, or cloud resource compromise) inherit the trust exemption.

Missing Validation Checks

Service providers sometimes fail to validate critical SAML assertion attributes:

• Audience restriction: Not verifying the assertion is intended for this SP
• Recipient validation: Not checking the assertion was sent to the correct endpoint
• Timestamp validation: Not enforcing NotBefore and NotOnOrAfter conditions
• Subject confirmation: Not validating the subject matches the authenticated user

Legacy Protocol Access

Many SaaS applications support legacy protocols (IMAP, POP3, SMTP) that predate SSO implementation. These protocols often accept basic authentication, creating a complete SSO bypass for attackers with credentials.

8. Subdomain Takeover for Cookie Theft

SSO session cookies scoped to parent domains create vulnerabilities when organizations abandon subdomains without properly decommissioning them.

Attack Mechanism

1. Organization deploys SSO with cookies scoped to *.company.com
2. Subdomain is abandoned (old-project.company.com points to expired cloud resource)
3. Attacker claims the abandoned subdomain by registering the expired resource
4. Attacker hosts malicious content on the subdomain
5. User visits the attacker-controlled subdomain
6. Attacker's JavaScript reads SSO cookies (because they're scoped to *.company.com)
7. Attacker replays stolen cookies to hijack the session

This attack requires no SSO vulnerability-just improper cookie scoping and abandoned infrastructure.

Why SSO Creates Unique Security Risks

Single Point of Failure

SSO's fundamental architecture creates concentrated risk. Every application trusts the SSO assertion without performing independent authentication. This trust model means:

• One compromise grants access to all connected applications
• No application-level defenses can prevent access with valid SSO tokens
• No fallback authentication exists if SSO is bypassed

Traditional multi-factor authentication at the application level provided defense in depth. Even if attackers compromised one application's credentials, they still needed to compromise each additional application independently. SSO eliminates this isolation.

The Trust Chain Problem

SSO creates a transitive trust relationship:

1. Service provider trusts the identity provider
2. Identity provider trusts the user authentication
3. User authentication trusts credentials and MFA

Attackers exploit this chain by attacking the weakest link. Forged SAML assertions bypass all three trust layers simultaneously. The service provider receives a cryptographically valid assertion and has no mechanism to verify the user actually authenticated.

Shadow IT Bypassing SSO

Not all applications in an organization use SSO. Shadow IT deployments, legacy systems, and applications deployed before SSO implementation often maintain independent authentication. These create:

• Visibility gaps: Security teams don't know these sessions exist
• Policy bypass: Users circumvent SSO policies and MFA requirements
• Credential sprawl: Users maintain separate passwords for each application
• Detection blind spots: Authentication events don't flow through central logging

Understanding how attackers target SaaS identities requires recognizing these gaps in SSO coverage.

Defending Against SSO Bypass

For Security Teams

1. Implement Phishing-Resistant Authentication

Traditional MFA (SMS codes, authenticator apps) remains vulnerable to phishing and session hijacking. Organizations should deploy:

• FIDO2 security keys: Hardware-based authentication resistant to phishing
• Passkeys: Platform-based authentication using biometrics and device binding
• Certificate-based authentication: Smart cards or device certificates

2. Monitor Post-Authentication Behavior

SSO bypass attacks often produce valid authentication events. Detection requires analyzing behavior after authentication:

• Geographic impossibilities
• Application access patterns inconsistent with user role
• Lateral movement between connected applications
• OAuth app authorization following SSO authentication
• Bulk data access or exfiltration

3. Audit All Authentication Paths

Security teams must inventory every way users can authenticate to each application:

• SSO (primary path)
• Local administrator accounts
• Legacy protocol access (IMAP, POP3, SMTP)
• API keys and service accounts
• Emergency access procedures

Each non-SSO path represents a potential bypass that requires monitoring or elimination.

4. Regular Security Assessments

IdP configuration requires regular security reviews:

• Certificate management: Rotate SAML signing certificates regularly
• Trust relationships: Audit all service providers with SSO access
• Policy enforcement: Verify MFA requirements apply universally
• Access reviews: Remove unused accounts and excessive permissions

5. Enforce SSO Universally

Eliminate authentication gaps by:

• Requiring SSO for all applications
• Disabling legacy protocol access
• Removing local authentication fallbacks
• Monitoring for applications bypassing SSO

For Developers

1. Properly Validate SAML Signatures

Use well-tested SAML libraries and ensure:

• Signature validation is required, not optional
• Certificate validation confirms the signing certificate
• Signature algorithms meet current security standards
• XML parsing cannot be manipulated through injection

2. Implement Token Replay Prevention

OAuth and OIDC implementations must:

• Enforce strict token lifetimes
• Implement one-time use for authorization codes
• Track token usage to detect replay attempts
• Bind tokens to specific devices or network contexts

3. Strict Validation Requirements

Service providers must validate all SAML assertion attributes:

• Audience: Assertion intended for this service provider
• Recipient: Assertion sent to correct endpoint
• Timestamps: NotBefore and NotOnOrAfter enforced
• Subject: Matches authenticated user context

4. Secure Session Management

After SSO authentication succeeds:

• Generate new session identifiers
• Implement session timeout policies
• Detect session hijacking through device fingerprinting
• Monitor for concurrent sessions from different locations

5. Remove Local Authentication

Eliminate or heavily restrict local authentication mechanisms:

• Remove administrative backdoors
• Disable legacy protocol support
• Require SSO even for service accounts
• Implement break-glass procedures that generate alerts

Detecting SSO Bypass Attacks

Golden SAML doesn't generate IdP authentication logs. Signature bypass looks like normal authentication at the service provider. Traditional security monitoring focused on failed logins, impossible travel, or MFA bypass alerts detects nothing because the authentication appears completely legitimate.

What Behavioral Detection Reveals

SSO bypass attacks reveal themselves through post-authentication behavior:

User "authenticated" but behavior doesn't match their pattern

• Accessing applications outside their normal workflow
• Performing administrative actions inconsistent with their role
• Bulk data access patterns not seen in historical behavior

Access to applications the user has never used before

• First-time access to sensitive applications
• Immediate privileged actions without exploration or learning
• Accessing applications outside the user's department or function

Session from geography inconsistent with user's history

• Authentication from countries the user has never accessed from
• Impossible travel (authenticated from New York, then Moscow 30 minutes later)
• ISP or ASN inconsistent with user's typical network providers

Lateral movement patterns after SSO authentication

• Rapid access to multiple connected applications
• OAuth app authorization immediately following SSO session
• API access patterns indicating automated enumeration
• Data access across applications suggesting reconnaissance

OAuth apps authorized immediately after SSO session established

• Consent grants without user interaction delay
• Multiple OAuth apps authorized in rapid succession
• Third-party integrations the user has never used before

The Golden SAML Detection Challenge

Golden SAML attacks produce no traditional indicators of compromise:

No failed logins to detect
No MFA bypass to alert on
No credential stuffing patterns
No brute force attempts
Token is cryptographically valid

Only behavioral anomalies reveal the attacker

This is why Identity Threat Detection and Response (ITDR) capabilities focus on behavioral analysis rather than authentication event monitoring. The authentication succeeds. The token validates correctly. Only the user's behavior after authentication reveals the compromise.

Recent SSO Vulnerabilities

   CVE Product Impact Year Exploitation Status    CVE-2025-47949 Samlify Auth bypass via signature wrapping 2025 Proof of concept   CVE-2025-59718 Fortinet FortiOS SSO bypass via SAML forgery 2025 Active exploitation   CVE-2025-59719 Fortinet Products SSO authentication bypass 2025 Active exploitation   CVE-2024-45409 ruby-saml Auth bypass via parser differential 2024 Proof of concept  

The Fortinet vulnerabilities demonstrate the severity of SSO bypass attacks in 2026. CVE-2025-59718 and CVE-2025-59719 allowed attackers to bypass FortiCloud SSO authentication and gain unauthorized access to FortiGate firewalls, FortiManager, FortiAnalyzer, and other security appliances.

Arctic Wolf identified coordinated attacks beginning January 15, 2026, involving:

• Creation of generic accounts for persistence
• Enabling VPN access through configuration changes
• Exfiltration of firewall configurations
• All actions occurring within seconds, indicating automated exploitation

These attacks succeeded against fully updated devices that had already been patched for previous vulnerabilities, demonstrating how new attack paths continue to emerge even in patched systems.

The SaaS Supply Chain Dimension

SSO bypass attacks become exponentially more dangerous in interconnected SaaS environments. Modern organizations don't just use individual SaaS applications-they connect them through OAuth integrations, API keys, and service accounts that create a SaaS supply chain.

How SSO Bypass Enables Supply Chain Attacks

When attackers bypass SSO to access one application, they inherit access to every application connected through OAuth tokens and API integrations:

1. Attacker bypasses SSO to access Salesforce
2. Salesforce has OAuth integration with marketing automation platform
3. Marketing platform connects to customer data platform
4. Customer data platform integrates with analytics tools
5. Each connection uses refresh tokens that persist independently of SSO

The attacker rides these trusted connections straight into customer environments, multiplying the blast radius of a single SSO bypass. As documented in the Stellantis breach, one compromised integration can extend into dozens of downstream applications.

OAuth Tokens Function Independently of SSO

This creates a critical misconception: OAuth refresh tokens continue functioning even after SSO sessions expire. Organizations believe SSO provides centralized control, but OAuth tokens operate in a hidden layer beyond SSO visibility.

When an attacker bypasses SSO and authorizes an OAuth app:

• The OAuth refresh token persists for months or years
• Token validity is independent of SSO session lifetime
• Revoking SSO access doesn't revoke OAuth tokens
• MFA requirements don't apply to token refresh flows

Understanding OAuth token abuse reveals how SSO bypass attacks establish persistent access that survives even after the initial breach is discovered.

Conclusion

SSO bypass attacks circumvent the authentication mechanisms organizations depend on to protect their entire application ecosystem. Unlike credential theft or brute-force attacks, SSO bypass techniques exploit the authentication protocol itself, creating valid sessions that traditional security controls cannot distinguish from legitimate access.

The eight attack techniques detailed in this analysis-from Golden SAML forgery to subdomain takeover-demonstrate that SSO creates a concentrated attack surface. When attackers bypass SSO, they bypass everything: MFA, conditional access policies, authentication logging, and application-level security controls.

Key Actions for Security Teams

Immediate priorities:

1. Audit all authentication paths to identify SSO bypasses and local authentication fallbacks
2. Implement behavioral detection because SSO bypass produces valid authentication events
3. Deploy phishing-resistant authentication (FIDO2, passkeys) to strengthen the auth