SSO and Token-Based Attacks

The $2.1M SSO Compromise

Monday, 2:47 PM. Marcus Webb, IT security analyst at Northfield Financial, receives an alert: unusual API activity from the company's Salesforce instance. Someone is exporting the entire customer database.

Marcus checks the access logs. The export is happening under the credentials of Rachel Torres, VP of Sales. But Rachel is in a client meeting. Her laptop is closed. She hasn't logged into Salesforce directly in weeks.

"I always use the company portal," Rachel explains when Marcus calls her. "I click the Salesforce icon and I'm in. Same with everything else."

That's when Marcus realizes the problem. Northfield uses Okta as their identity provider. Every employee logs in once to Okta, then accesses all company applications through single sign-on. One login unlocks everything.

Marcus pulls Okta's authentication logs. Last Friday, Rachel received an email that looked like an Okta password reset notification. She clicked the link and landed on what appeared to be the Okta login page. She entered her password. A few seconds later, her phone buzzed with an Okta push notification asking her to approve the login. She tapped "Yes." The page showed a brief error message, then redirected her to the real Okta dashboard. She assumed it was a glitch and went on with her day.

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

For three days, the attackers used Rachel's Okta access to authenticate into every application connected to her account: Salesforce, the internal banking system, the document management platform, the HR portal. The attackers exported customer records, downloaded financial reports, and harvested employee data. By the time Marcus caught them, they had accessed 847 accounts across 12 applications.

The total cost: $2.1 million in incident response, regulatory fines, and customer notification.

Rachel's passwords for each individual application were strong and unique. Her MFA was enabled. None of that mattered. The attackers never touched those systems directly. They walked in through the front 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 article explains how federated authentication works, why it creates vulnerabilities, and how attackers exploit the trust relationships between systems.

How Single Sign-On Works

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.

Consumer vs Enterprise SSO

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 Traditional Alerts Fail

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, Azure AD)
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 This Matters 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 password alone. 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. SMS codes technically qualify, but they're vulnerable to SIM swapping. Authenticator apps (TOTP) and push notifications meet AAL2 but can still be phished in real-time or bypassed through push fatigue.

AAL3 requires a hardware authenticator that resists verifier impersonation. This means the authentication can't be phished because the hardware key verifies it's communicating with the legitimate service. FIDO2 security keys and passkeys meet this requirement.

Identity Assurance Level (IAL)

IAL measures confidence that a person's claimed identity is real during account creation.

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 Attackers Think About Assurance Levels

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 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 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.

How 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 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.

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.

Limitations

Passkeys require device and browser support. Account recovery becomes more complex since there's no password to reset. If you lose your device without backup, you may lose access to accounts.

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

---

Generated with AI assistance. Reviewed by humans for accuracy.