You log into your company’s identity provider once in the morning, and suddenly you can access Slack, Salesforce, GitHub, AWS, and forty other services without typing another password. That’s single sign-on. It’s convenient. It’s a security improvement over fifty separate passwords. And it’s a single point of failure that, if compromised, hands an attacker the keys to your entire digital life.

SSO and federation solve real problems — password fatigue, inconsistent access policies, unmanageable credential sprawl. But they do it by concentrating trust into a small number of identity providers. Understanding how that trust gets delegated, what protocols carry it, and where things go wrong isn’t optional knowledge anymore. It’s survival.

The TLDR

Single sign-on (SSO) lets you authenticate once and access multiple services. Federation extends this across organizational boundaries — your company’s identity provider can assert your identity to a partner’s services. SAML 2.0 is the enterprise workhorse: XML-based, mature, complex. OAuth 2.0 handles authorization (what you can access) while OpenID Connect (OIDC) layers authentication (who you are) on top of it. The Identity Provider (IdP) holds credentials and issues assertions. Service Providers (SPs) or Relying Parties consume those assertions. The security model depends entirely on protecting the IdP, validating tokens properly, and managing sessions. NIST SP 800-63C covers federation assurance levels, and the stakes are high — a compromised IdP means total compromise of every connected service.

The Reality

Before SSO, enterprise environments looked like this: every application maintained its own user database, its own password policy, its own login page. People had dozens of credentials, wrote them on sticky notes, reused them everywhere. When someone left the company, IT had to manually disable accounts in every single system — and they always missed a few. Deprovisioning was incomplete by default.

SSO solved the credential sprawl problem. One identity, one set of credentials, one place to enforce MFA, one kill switch when someone leaves. That’s genuinely better. But it also created a new problem: concentration of risk. When your IdP is the entry point for everything, compromising it is the attacker equivalent of winning the lottery.

The 2020 SolarWinds attack demonstrated this at national scale. The threat actor (attributed to Russia’s SVR by CISA) compromised on-premises ADFS servers, forged SAML tokens, and used them to access cloud services including Microsoft 365 and Azure. They didn’t need to phish individual credentials — they forged the identity assertions themselves. When you own the IdP, you own everything downstream.

How It Works

The Players

Every federated authentication flow involves the same cast:

SAML 2.0 — The Enterprise Standard

SAML (Security Assertion Markup Language) has been the enterprise SSO standard since 2005. It’s XML-based, verbose, and battle-tested.

The SP-Initiated Flow (most common):

  1. You navigate to the SP (e.g., salesforce.com).
  2. The SP doesn’t have an active session for you. It generates an AuthnRequest — an XML document requesting the IdP to authenticate you.
  3. Your browser is redirected to the IdP with the AuthnRequest (via HTTP redirect or POST).
  4. The IdP authenticates you (password, MFA, whatever the policy requires).
  5. The IdP constructs a SAML Response containing an Assertion — a signed XML document stating your identity, attributes (email, groups, roles), and validity period.
  6. Your browser POSTs the SAML Response back to the SP’s Assertion Consumer Service (ACS) URL.
  7. The SP validates the XML signature, checks the assertion’s conditions (not expired, correct audience), extracts your attributes, and creates a local session.

The entire assertion is digitally signed by the IdP’s private key. The SP verifies it with the IdP’s public key (exchanged during trust setup). Tampering with the assertion invalidates the signature. That’s the security model — it all hinges on the integrity of that signature.

OAuth 2.0 and OpenID Connect — The Modern Stack

OAuth 2.0 and OIDC are often confused. Here’s the distinction:

The Authorization Code Flow (OIDC):

  1. You click “Sign in with Google” on an application.
  2. The application redirects you to the IdP’s authorization endpoint with a request specifying openid scope (and any additional scopes like profile, email).
  3. The IdP authenticates you and asks for consent (“This app wants to see your name and email — allow?”).
  4. The IdP redirects back to the application’s callback URL with an authorization code — a short-lived, one-time-use code.
  5. The application’s backend exchanges the authorization code for an ID Token (JWT containing identity claims), an access token (for API access), and optionally a refresh token (for getting new access tokens without re-authentication).
  6. The application validates the ID Token (signature, issuer, audience, expiration) and creates a local session.

The authorization code flow is designed so that tokens never pass through the browser — the code-for-token exchange happens server-to-server. This is important because browser URLs end up in logs, history, and referrer headers.

JWTs (JSON Web Tokens) are the carrier format. A JWT has three parts: header (algorithm, key ID), payload (claims — issuer, subject, audience, expiration, custom claims), and signature. They’re Base64-encoded and signed, not encrypted by default. This means anyone can read the claims — the signature only guarantees they weren’t tampered with. If the token contains sensitive data, it should be a JWE (JSON Web Encryption) — but most implementations use signed JWTs for ID tokens and opaque tokens for access tokens.

Federation Trust Models

Hub-and-spoke: A central IdP (the hub) federates with multiple SPs (the spokes). Most enterprise SSO deployments look like this. Your Okta or Azure AD is the hub; Salesforce, AWS, and Slack are the spokes.

Mesh federation: Multiple IdPs trust each other, enabling cross-organizational authentication. Academic networks like InCommon use this model — a student at University A can access resources at University B because both participate in the federation.

Transitive trust: IdP-A trusts IdP-B, IdP-B trusts IdP-C. Does IdP-A trust IdP-C? In most federation models, no — trust is explicitly configured between pairs, not transitive. This is a deliberate security decision. Transitive trust is how you get uncontrolled access chains.

How It Gets Exploited

Golden SAML Attacks

If an attacker compromises the IdP’s token-signing certificate, they can forge SAML assertions for any person, with any attributes, for any connected SP. This is the “Golden SAML” attack, named by analogy with Golden Ticket attacks in Kerberos. The SolarWinds attackers used exactly this technique — they stole the ADFS token-signing certificate and forged assertions to access cloud services as any person in the organization. MITRE ATT&CK T1606.002 (Forge Web Credentials: SAML Tokens) documents this technique.

The defense is brutally simple in concept and difficult in practice: protect the token-signing certificate with hardware security modules (HSMs), rotate it regularly, and monitor for anomalous assertion patterns. If you see SAML assertions being issued outside of normal authentication flows, that’s a five-alarm fire.

Token Replay and Session Hijacking

SAML assertions and OAuth tokens are bearer instruments — whoever possesses them can use them. If an attacker captures a valid assertion or access token (through man-in-the-middle, XSS, or log exposure), they can replay it to gain access. Mitigations include short token lifetimes, audience restrictions, one-time-use assertions, and binding tokens to specific clients. MITRE ATT&CK T1550.001 (Use Alternate Authentication Material: Application Access Token) covers token-based lateral movement.

Session hijacking is the related threat — instead of replaying the token, the attacker steals the session cookie that was created after successful SSO authentication. Browser extensions, XSS vulnerabilities, and malware can all exfiltrate session cookies. This bypasses MFA entirely because the MFA challenge already happened during the SSO flow.

OAuth Phishing and Consent Attacks

Instead of stealing credentials, an attacker creates a malicious OAuth application and tricks you into granting it permissions. “Super Cool Productivity App wants access to your email, calendar, and files — Authorize?” You click yes, and the attacker’s app now has an access token to read your email. This is a consent phishing attack, and it doesn’t trigger MFA prompts because you’re the one authorizing the access. Microsoft has specifically warned about OAuth consent phishing as an increasing threat vector.

XML Signature Wrapping

SAML assertions are signed XML documents, and XML signature validation is notoriously tricky. XML Signature Wrapping attacks exploit differences between which part of the XML the signature validates and which part the application processes. The attacker injects a forged assertion alongside the legitimately signed one, arranged so that the signature validates against the original but the application processes the forged one. This class of vulnerability has been found in multiple SAML implementations. Proper defenses require strict XML parsing, schema validation, and canonicalization — details that many developers get wrong.

What You Can Do

Harden your IdP like it’s the crown jewels — because it is. MFA on every admin account. Hardware keys preferred. Monitor admin activity obsessively. The IdP is the highest-value target in your entire environment.

Protect token-signing certificates. Store them in HSMs. Rotate them on a schedule. Monitor for unauthorized export or use. If you’re using ADFS, consider migrating to a cloud IdP where certificate management is handled by the provider.

Enforce short token lifetimes. SAML assertions should be valid for minutes, not hours. Access tokens should expire quickly and require refresh token rotation. Shorter lifetimes limit the window for replay attacks.

Monitor for anomalies. Impossible travel (authentication from two countries in five minutes), unusual service access patterns, SAML assertions issued outside of normal flows — these are indicators of compromise. CISA’s guidance on detecting post-compromise activity in federated environments is essential reading.

Review OAuth application consents. Audit which third-party applications have been granted access to your organization’s data. Revoke anything unnecessary. Restrict the ability to consent to new applications to admins only in high-security environments.

Sources & Further Reading