SSO and Token-Based Attacks

Single sign-on and federated identity let one login unlock dozens of applications, which is convenient for users and concentrates risk in the identity provider. When attackers compromise an SSO account or steal the tokens it issues, every downstream application sees a legitimate, MFA-satisfied login. This article covers how SAML, OAuth, and OIDC pass identity between systems, how real-time phishing proxies and token theft bypass the controls those protocols rely on, and where passkeys close the loop that passwords leave open.

The $2.1M SSO Compromise

Marcus got the alert at 2:47 PM. Unusual API activity from Salesforce. Someone was exporting the entire customer database.

He checked the access logs. The export was running under the credentials of Rachel Torres, VP of Sales. But Rachel was in a client meeting. Laptop closed. She hadn't logged into Salesforce directly in weeks.

He called her. "I always use the company portal," she said. "Click the Salesforce icon, I'm in. Same with everything."

That was the problem. Northfield used Okta for single sign-on. One login unlocked everything.

Marcus pulled Okta's authentication logs. Last Friday, Rachel had received what looked like an Okta password reset email. She'd clicked the link, entered her password on what appeared to be the Okta login page. Her phone buzzed with a push notification to approve the login. She tapped yes. Brief error message, then redirect to her normal dashboard. She'd assumed it was a glitch.

It wasn't. The phishing page was a proxy. When Rachel entered her password, the attacker's server sent it to the real Okta in real-time. When she approved the MFA push, she was authenticating the attacker. They captured the session token before forwarding her to the legitimate site.

For three days, the attackers used Rachel's Okta session to access every connected application. Salesforce. The internal banking system. The document management platform. HR portal. By the time Marcus caught them, they'd hit 847 accounts across 12 applications.

Rachel's passwords were strong and unique. MFA was enabled everywhere. None of it mattered. They'd walked in through the one door that unlocked every room in the building.

This story is fictional, but the patterns are real.

Why This Matters

Account Security Fundamentals covered how authentication factors work and how attackers bypass MFA. But modern authentication has evolved beyond standalone passwords and tokens. Today's systems use federated identity, where one login grants access to dozens of applications.

This shift created efficiency. Employees don't need separate passwords for every system. IT teams can manage access from a central dashboard. Users can "Login with Google" instead of creating new accounts for every service.

It also created new attack surfaces. When a single identity provider controls access to everything, compromising that provider is like stealing a master key. The attacker doesn't need to break into each application separately. They authenticate once, legitimately, and walk through every door. This is the kind of third-party fraud described in common fraud types, but with the IdP as the leverage point rather than a single account.

This article explains how federated authentication works, why it creates vulnerabilities, and how attackers exploit the trust relationships between systems.

How Does Single Sign-On Work?

Single sign-on (SSO) lets users authenticate once and access multiple applications without logging in again. Instead of each application verifying credentials independently, they all trust a central identity provider.

The Identity Provider Model

An identity provider (IdP) is the system that verifies who you are. Common examples:

When you click "Login with Google" on a website, you're telling that website: "Don't verify my identity yourself. Ask Google, and trust whatever Google says."

The website never sees your Google password. Instead, Google confirms your identity and issues a token proving you authenticated successfully. The website accepts this token and lets you in.

How Do Consumer and Enterprise SSO Differ?

Consumer SSO (social login) is optional. You can create a separate account on most websites or use Google, Apple, or Facebook to log in. If your Google account is compromised, the attacker can access any site where you chose "Login with Google."

Enterprise SSO is mandatory. Employees access all company applications through a single identity provider. This is convenient, but it means the IdP becomes a single point of failure. Compromise one account, access everything that account is connected to.

In Marcus's investigation, Rachel didn't choose to use Okta. Company policy required it. Every application she needed for her job trusted Okta as the source of truth for her identity.

Why Do Traditional Alerts Fail Against IdP Attacks?

When attackers compromise an IdP, they generate legitimate authentication tokens. From the perspective of each connected application:

• The login came from the identity provider (trusted)
• The authentication token is valid (properly signed)
• MFA was satisfied (at the IdP, before compromise)
• No failed login attempts occurred

Every application sees a normal, successful login. Rachel's Salesforce, banking system, and HR portal all received valid tokens from Okta. They had no way to know those tokens were issued to an attacker pretending to be Rachel.

The Protocols Behind SSO

SSO relies on protocols that define how identity providers and applications communicate. The three you'll encounter most often are SAML, OAuth, and OpenID Connect (OIDC).

SAML: The Enterprise Standard

Security Assertion Markup Language (SAML) is the dominant protocol for enterprise SSO. When Rachel clicked the Salesforce icon in her company portal, SAML handled the authentication behind the scenes.

SAML works through XML-based messages called assertions. When you access an enterprise application:

1. The application redirects you to your identity provider (Okta, Microsoft Entra ID)
2. You authenticate with the IdP
3. The IdP sends a signed SAML assertion back to the application
4. The application trusts the assertion and grants access

SAML was designed in the early 2000s for browser-based enterprise applications. It's verbose and complex, but it's deeply embedded in corporate IT infrastructure. If you're investigating fraud at a large organization, their internal SSO almost certainly runs on SAML.

OAuth: Authorization, Not Authentication

OAuth was designed for authorization, not authentication. It answers the question: "What is this application allowed to do?" rather than "Who is this user?"

The classic example: you want a photo printing service to access your Google Photos. OAuth lets you grant that service permission to read your photos without giving it your Google password.

OAuth uses tokens to represent permissions:

When you authorize an application through OAuth, it receives tokens that grant specific permissions. The application can use these tokens to act on your behalf without knowing your password.

OIDC: Adding Identity to OAuth

OpenID Connect (OIDC) adds an authentication layer on top of OAuth. It answers: "Who is this user?"

OIDC introduces the ID token, which contains information about the user: their name, email, and a unique identifier. When you "Login with Google," the website receives an ID token proving you authenticated with Google, plus access tokens for any permissions you granted.

Which Protocol Does What?

In practice, these often work together. An enterprise might use SAML for internal application SSO while their customer-facing products use OIDC for social login.

Why Does Protocol Choice Matter for Fraud?

All three protocols issue tokens or assertions that attackers can steal or abuse:

Token theft. If an attacker steals your access or refresh tokens, they can impersonate you without knowing your password. Tokens are stored in browser cookies, local storage, or application memory. Malware can extract them.

Long-lived refresh tokens. Access tokens expire quickly, but refresh tokens can last for months. One stolen refresh token provides persistent access until the user or administrator revokes it.

Scope abuse. OAuth permissions (called "scopes") determine what the token holder can do. An application that requested broad permissions gives attackers broad access if its tokens are compromised.

SAML assertion replay. If attackers capture a SAML assertion before it expires, they can replay it to gain access. SAML assertions typically have short validity windows (minutes), but that's enough time to establish a session.

NIST Assurance Levels

The National Institute of Standards and Technology (NIST) defines frameworks for measuring authentication and identity strength. Understanding these levels helps you assess how difficult an attack would be against a given system.

Authentication Assurance Level (AAL)

AAL measures how confident you can be that the person logging in is who they claim to be.

AAL1 systems accept a single authentication factor, typically a password. These are vulnerable to credential stuffing, password spraying, and basic phishing.

AAL2 requires multi-factor authentication. The second factor must provide cryptographic proof of possession. Under NIST SP 800-63B Rev 4 (2025), SMS OTP is classified as a "restricted authenticator." It is still permitted at AAL2, but only with documented risk mitigation, user notification, and a migration plan to stronger factors.^[1] Authenticator apps (TOTP) and push notifications meet AAL2 but can still be phished in real-time or bypassed through push fatigue. Synced (multi-device) passkeys are phishing-resistant and qualify for AAL2.

AAL3 requires two distinct factors, with at least one hardware-based cryptographic authenticator that has a non-exportable private key and resists verifier impersonation.^[1] The authentication can't be phished because the hardware key verifies it's communicating with the legitimate service. Device-bound FIDO2 security keys meet AAL3. Synced passkeys do not qualify because their private keys are exportable across devices.

Identity Assurance Level (IAL)

IAL measures confidence that a person's claimed identity is real during account creation. This is the same dimension that KYC 101 covers from an onboarding perspective; IAL is how NIST formalises it.

IAL1 means the user told you who they are and you took their word for it. Creating a fake account requires nothing more than invented information.

IAL2 requires evidence. Typically, this means scanning a government ID and answering knowledge-based questions. Attackers can forge documents or use information from data breaches to answer questions correctly.

IAL3 requires physical presence. Someone verifies your identity face-to-face against government documents. This is rare because it's expensive and inconvenient.

How Do Attackers Use Assurance Levels to Pick Targets?

An attacker evaluating a target considers both levels. A system with strong authentication (AAL3) but weak identity proofing (IAL1) is vulnerable to synthetic identity fraud. An attacker creates a fake account, then has full access using credentials they control.

A system with weak authentication (AAL1) but strong identity proofing (IAL2) is vulnerable to credential attacks. Real accounts exist, but passwords can be stolen or guessed.

The strongest systems combine high assurance on both dimensions. Most real-world systems don't.

How Do SSO and Token Attacks Work?

Understanding attack patterns helps you recognize when federated systems are being exploited.

IdP Credential Theft

The most direct attack: steal credentials for the identity provider itself. Once attackers control an IdP account, they can authenticate to any connected application.

Modern phishing attacks use real-time proxies. The fake login page doesn't just collect credentials. It forwards them to the real identity provider immediately. When the IdP sends an MFA challenge, the victim receives it on their phone and approves it, thinking they're authenticating themselves. The proxy captures the resulting session token.

In Rachel's case, she approved a legitimate Okta push notification. She just didn't realize the login attempt came from attackers using her password on their machine. The error message and redirect made the experience feel like a minor glitch, not a security breach.

Key characteristics:

• Attack happens outside the target application's visibility
• All generated tokens are legitimate
• MFA is bypassed because the victim approves it themselves
• Individual applications see normal, successful logins

Real-Time Phishing Proxies

Tools like Evilginx act as reverse proxies between victims and legitimate sites. The victim usually arrives there through a phishing email or message, so the email authentication layer matters here as a first line of defence. The victim sees a convincing login page. Everything they type flows through the attacker's server to the real site. Everything the real site sends back flows through the attacker's server to the victim.

This means the attacker captures whatever the legitimate site returns after authentication:

The victim completes the entire authentication flow, including MFA. The attacker harvests the results. This is why Rachel's push notification approval gave attackers everything they needed. She authenticated legitimately. The proxy just copied what Okta sent back.

Session Token Theft

Session tokens maintain logged-in state. When you authenticate to a website, you receive a session cookie that proves you already logged in. Present that cookie, and you skip authentication entirely.

Beyond phishing proxies, attackers steal session tokens through:

• Malware. Infostealers extract cookies from browser storage
• Cross-site scripting (XSS). Malicious scripts on compromised pages read cookie values
• Man-in-the-middle attacks. Intercepting traffic on unsecured networks

A stolen session token provides immediate access without needing credentials or MFA. The victim stays logged in on their device while the attacker uses the same session from another location.

OAuth Token Theft

OAuth access and refresh tokens are stored in browser local storage, cookies, or application memory. Extracting them provides ongoing access.

Refresh tokens are particularly valuable. Access tokens expire quickly, but a refresh token can generate new access tokens for months. One stolen refresh token means persistent access until explicitly revoked.

Push Fatigue

Push notification MFA asks users to approve login attempts on their phone. Attackers who have stolen a password can trigger repeated push notifications.

The attack: send dozens of push notifications in rapid succession. Eventually, the victim approves one just to make them stop, or accidentally taps "Approve" while trying to dismiss the alerts.

This attack requires the attacker to already have the victim's password. It bypasses MFA by exploiting human frustration rather than technical vulnerability.

Securing Stolen Access

Once attackers compromise an account, they often add their own authentication factors to maintain access and lock out the legitimate owner.

Common techniques:

• Enroll a new phone number for SMS-based MFA
• Register their own authenticator app as a second factor
• Add a passkey tied to their device
• Enable biometric login on a device they control
• Change the recovery email to one they own

This flips authentication security on its head. The same mechanisms designed to protect accounts now protect the attacker's access. The legitimate owner can't log in because they don't control the enrolled authenticators. Account recovery becomes difficult because the attacker changed the recovery options.

When investigating account takeovers, check for authenticator changes made shortly after suspicious access. A new MFA device enrolled right after a login from an unusual location is a strong signal that someone is securing stolen access.

Passkeys and Phishing-Resistant Authentication

FIDO2 and passkeys represent a different approach to authentication. Unlike passwords, they can't be phished. The FIDO Alliance describes passkeys as "phishing resistant and secure by design" and "guaranteed to be unique per app/website/service."^[2]

How Do Passkeys Work?

A passkey is a cryptographic credential stored on your device. When you register with a website, your device generates a public-private key pair. The website stores the public key. Your device keeps the private key, protected by biometrics or a PIN.

When you log in, the website sends a challenge. Your device signs the challenge with the private key and sends it back. The website verifies the signature using the public key. At no point does a shared secret (like a password) leave your device.

Why Do Passkeys Resist Phishing?

Passkeys are bound to specific domains. If you register a passkey for bank.com, it will only work on bank.com. A phishing site at bank-login.com cannot use your passkey because it's a different domain.^[2]

Even if you click a phishing link and try to authenticate, your device won't offer the passkey for the wrong domain. The attack fails automatically. NIST classifies this verifier-name binding (as implemented in WebAuthn/FIDO2) as one of the two acceptable forms of phishing resistance.^[1]

Limitations

Passkeys require device and browser support. Recovery depends on the passkey type. Synced passkeys (stored in iCloud Keychain, Google Password Manager, 1Password, etc.) follow your account-level recovery flow, so losing one device usually does not lock you out. Device-bound passkeys have no such fallback. If you lose the device and don't have a backup authenticator registered, you can lose access to accounts that rely on that key.

Organizations deploying passkeys often keep password authentication as a fallback, which reintroduces phishing risk. The security benefit only applies when passkeys are the primary or only authentication method.

Key Takeaways

• SSO creates single points of failure. One compromised identity provider account grants access to every connected application, as Marcus discovered when attackers used Rachel's Okta credentials to access 847 accounts across 12 systems.
• Token theft bypasses authentication entirely. Attackers who steal session tokens or OAuth refresh tokens can impersonate users without knowing their credentials or triggering MFA.
• Traditional alerts fail against IdP attacks. When attackers authenticate through a compromised identity provider, every connected application sees legitimate tokens. No failed logins, no password changes, no anomalies to detect.
• AAL and IAL measure different risks. Authentication Assurance Level measures login strength; Identity Assurance Level measures identity verification. Strong systems need both.
• Passkeys resist phishing by design. Domain binding means credentials only work on the legitimate site. Phishing pages can't use passkeys registered for other domains.

What's next: Attack Methods covers SIM swapping, social engineering, and other techniques attackers use to compromise accounts.

Key Terms

References

1. NIST Special Publication 800-63B: Digital Identity Guidelines, Authentication and Authenticator Management (2025)↗ (AAL1/AAL2/AAL3 definitions; SMS-over-PSTN as restricted authenticator; phishing resistance via channel binding or verifier-name binding such as WebAuthn/FIDO2)

2. FIDO Alliance: Passkeys↗ ("phishing resistant and secure by design"; passkeys "guaranteed to be unique per app/website/service")