Identity Federation: SSO, SAML & OAuth/OIDC

Why Identity Federation Exists

The Cost of One Identity Per App

Before federation, the default pattern was one identity per application. Every SaaS tool, internal web app, and vendor portal maintained its own user database, its own password hashing, its own account recovery flow. At the scale of a handful of tools this is annoying but survivable.

At enterprise scale, with dozens or hundreds of applications, it becomes a structural liability. Employees reuse passwords because remembering a hundred unique ones is unrealistic, and IT loses visibility into who has access to what because provisioning and deprovisioning happen independently in every application's own admin console. When someone leaves the company, offboarding means chasing down access in every one of those separate systems, and missed accounts are exactly how ex-employees retain access long after they should not.

How Federation Restructures the Problem

Identity federation restructures this around a single trusted source of truth: the Identity Provider, or IdP. Instead of each application authenticating users itself, the application (the Service Provider or relying party) trusts the IdP to do that job and simply accepts the IdP's word for who the user is.

The user authenticates once, to the IdP, and that authentication event is then recognized across every federated application without typing a password into each one separately. This is what people mean by Single Sign-On (SSO): not that there is only one login screen in the org, but that one authentication event at the IdP establishes trust everywhere the IdP is trusted.

The Security Payoff

Centralizing authentication at the IdP means MFA, conditional access policies, and login anomaly detection only need to be enforced in one place to protect access to everything downstream. A single admin console, the IdP's, becomes the actual source of truth for who can reach what, which makes access reviews and offboarding tractable instead of a scavenger hunt across a hundred separate admin panels.

Deactivating one account at the IdP instantly cuts off access to every federated application at once, rather than requiring a separate deprovisioning step per app.

The Tradeoff: Concentrated Trust

Federation is not free of tradeoffs, it concentrates risk. If the IdP itself is compromised, or if the credential that proves the IdP's identity to relying applications is stolen, an attacker inherits trust across every application that trusts the IdP, not just one.

That concentration of trust is precisely why IdP infrastructure, particularly the private keys and certificates it uses to sign its assertions, is treated as some of the highest-value infrastructure in an enterprise environment. It is also why attacks against that signing material, covered later in this chapter under Golden SAML, are so consequential when they succeed.

Getting the Vocabulary Straight

SSO, federation, and identity provider get used loosely in casual conversation, but they describe different things. SSO describes the user experience: log in once, reach many applications. Federation describes the underlying trust architecture that makes SSO possible across organizational or system boundaries, an SP trusting assertions issued by an external IdP rather than maintaining its own separate authentication.

The IdP is the specific system, Okta, Microsoft Entra ID, Google Workspace, or an on-premises system like Active Directory Federation Services, that authenticates the user and issues the proof of that authentication to everything else.

The SSO Model: IdP and Service Provider

Every federated SSO relationship has two named parties, and the vocabulary is consistent across SAML, OAuth, and OIDC even though the exact mechanics differ. The Identity Provider (IdP) owns the authoritative record of who a user is and is responsible for actually verifying their identity, typically through a password plus MFA.

The Service Provider (SP), sometimes called the relying party depending on the protocol, is the application the user wants to reach. The SP does not verify the password itself; it delegates that job entirely to the IdP and instead verifies that the proof the IdP handed back is genuine and intact.

Establishing Trust Is a One-Time Setup

Establishing this trust relationship is a one-time configuration step, not something negotiated per login. An administrator configures the SP and IdP to trust each other by exchanging metadata: the IdP's public signing certificate (so the SP can verify signatures on anything the IdP issues), the SP's expected entity ID or client identifier, and the specific endpoints each side will use during the login flow.

Vendor documentation from providers like Okta and Microsoft Entra ID walks through this exact metadata exchange as the setup step before any user can actually log in through the integration.

The Login Flow at a High Level

Once trust is configured, the basic flow is consistent at a conceptual level regardless of which protocol carries it:

1. User attempts to reach the SP. The application checks whether the user is already authenticated.
2. SP redirects to the IdP if the user is not already authenticated there.
3. User proves their identity to the IdP, via password, MFA, or whatever policy requires.
4. IdP sends the SP signed proof that this specific user successfully authenticated.
5. SP validates that proof, cryptographically confirming it came from the trusted IdP and was not tampered with, then establishes its own local session for the user.

From that point forward, the user interacts with the SP using its own session mechanism, typically a cookie, without needing to go back to the IdP again until that session expires or the SP requires re-authentication.

Sessions Don't Keep Checking Back With the IdP

A critical detail that trips up a lot of people new to this space: once the SP has validated the IdP's proof and created a local session, the SP is not continuously checking back with the IdP on every request. The federation protocol governs how the initial trust gets established, not how the ongoing session is maintained afterward.

This matters operationally. If an account is disabled at the IdP mid-session, the user's existing SP session does not necessarily die immediately, it depends entirely on how that specific SP is configured to handle session lifetime and revocation, which is exactly the kind of gap that shows up in real security assessments of SSO deployments.

Why This Separation Scales

The IdP/SP model scales well because it cleanly separates two concerns that used to be tangled together in every application: authenticating a user, and doing whatever the application actually does. Application developers no longer need to build and secure their own password storage, MFA flow, and account recovery process; they consume a standardized proof of identity from a specialized system built for exactly that job.

This is also why federation protocols show up constantly in real environments. Almost every enterprise SaaS product supports SAML or OIDC login specifically so it can plug into whatever IdP the customer already runs.

SAML: Assertions and the IdP-Initiated/SP-Initiated Flows

Security Assertion Markup Language (SAML) 2.0, standardized by OASIS, is the older and still widely deployed federation protocol, especially common in traditional enterprise environments and applications that predate the modern OAuth/OIDC ecosystem. SAML is XML-based, and its core artifact is the assertion: a signed XML document the IdP produces that makes specific statements about a user, wrapped inside a larger SAML Response message that the IdP sends to the SP.

What's Inside a SAML Assertion

A SAML assertion has real structure, not just an opaque blob:

• Subject. Identifies who the assertion is about, typically carried in a NameID element that serves as the unique identifier the SP will recognize for that user.
• Conditions. A validity window defined by NotBefore and NotOnOrAfter timestamps, so an assertion cannot be replayed indefinitely.
• AudienceRestriction. Names the specific SP the assertion was issued for. This is the mechanism that stops an assertion issued for one application from being reused to log into a different one, because a receiving SP is expected to check that it is actually the named audience before accepting the assertion.
• AuthnStatement. Records that authentication happened and when.
• AttributeStatements. Often carry additional user attributes like email address, group membership, or department.

The Signature: What Makes It Trustworthy

The entire assertion, or the enclosing Response, is digitally signed by the IdP using its private signing key, following the XML Signature standard. The SP already has the IdP's public certificate from the initial trust setup, and it uses that certificate to verify the signature is valid and the assertion has not been altered in transit, without needing to call the IdP back to confirm anything.

This signature is the single most security-critical piece of the whole SAML trust model, the only thing standing between "this assertion genuinely came from our trusted IdP" and "this assertion could have been forged by anyone." That property is exactly what the Golden SAML attack, covered later in this chapter, targets directly.

SP-Initiated vs IdP-Initiated Flow

SAML supports two distinct login flows that differ in where the process starts. SP-initiated is the more common pattern, for a user typing a URL directly into their browser and being bounced to a login page:

1. User starts at the application (SP). They try to reach the SP directly and it recognizes it needs to authenticate them.
2. SP sends an AuthnRequest to the IdP.
3. User authenticates at the IdP, which issues a signed SAML Response.
4. SP validates the response, partly by matching an InResponseTo reference back to the ID of its original AuthnRequest.

In IdP-initiated SSO, the user starts at the IdP itself, for example by clicking an application tile on an IdP dashboard like Okta's or Microsoft Entra ID's My Apps portal, and the IdP sends an unsolicited SAML Response straight to the SP without any prior request from that SP. Both flows are legitimate and widely supported, but IdP-initiated flows carry a structurally weaker validation story for the SP since there is no original request to match the response against.

Some security guidance recommends disabling IdP-initiated SSO where it is not specifically needed, for exactly this reason.

Why SAML Still Matters

SAML's XML-heavy design is often criticized as verbose compared to the JSON-based tokens used in OAuth and OIDC, and that criticism has some merit for developer experience. But the underlying trust model, signed assertions with explicit audience and validity constraints, is sound and battle-tested, which is a large part of why SAML remains deeply embedded in enterprise environments even as newer applications increasingly default to OIDC instead.

OAuth 2.0: Roles and Grant Types

OAuth 2.0, defined in RFC 6749, is frequently misunderstood as a login protocol. It is not, at least not by itself; it is an authorization framework, built to solve a specific problem: how does a third-party application get limited, scoped access to a resource on a user's behalf, without that application ever seeing the user's actual password. The canonical example is a photo-printing app that needs to read your photos from a cloud storage account without you ever typing your cloud storage password into the printing app.

The Four Roles

OAuth defines four roles that every flow involves. Keeping these straight is the foundation for understanding every OAuth flow, because each grant type is really just a different way of getting a token from the authorization server into the client's hands, appropriate to how much that client can be trusted.

• Resource owner. The user who owns the data or account being accessed.
• Client. The application requesting access, the photo-printing app in the example above.
• Authorization server. Authenticates the resource owner and issues access tokens once they approve the request. This role is often filled by the same infrastructure that functions as an IdP in a federation context.
• Resource server. The API that actually holds the protected data and accepts the access token as proof of authorized access.

Authorization Code + PKCE: The Default

The Authorization Code grant is the default choice for the overwhelming majority of real-world web applications today. The client never directly handles the resource owner's credentials, and the actual access token exchange happens through a back-channel server-to-server call rather than through the user's browser, which limits exposure.

The flow redirects the user to the authorization server to authenticate and approve the requested scope, then returns a short-lived authorization code to the client, which the client exchanges for an access token in a separate, more secure request. Modern implementations pair this grant with PKCE (Proof Key for Code Exchange), originally designed for mobile and single-page apps that cannot safely hold a client secret but now recommended broadly as a defense against authorization code interception.

Client Credentials: Machine-to-Machine

The Client Credentials grant serves a different scenario entirely: machine-to-machine communication where there is no human resource owner involved at all, just a backend service authenticating as itself to access an API. A batch job that needs to call an internal API on its own behalf, not on behalf of any specific user, is the textbook use case.

Two Deprecated Grants to Recognize

Two older grant types are now explicitly discouraged in current OAuth security guidance:

• Implicit grant. Returned the access token directly in the browser's URL fragment and skipped the authorization code exchange step. Deprecated; current OAuth 2.0 security best practice guidance recommends using Authorization Code with PKCE instead, even for browser-based apps that cannot hold a secret.
• Resource Owner Password Credentials (ROPC) grant. Had the client collect the user's actual username and password directly and exchange them for a token, defeating much of the point of OAuth in the first place. Deprecated, and removed entirely from the OAuth 2.1 draft specification.

Recognizing why these two grants fell out of favor is a useful lens for understanding OAuth security generally: nearly every OAuth hardening recommendation exists to keep the resource owner's actual credentials, and any long-lived token that could stand in for them, out of the hands of parties that do not strictly need them.

OpenID Connect: Authentication on Top of OAuth

The Gap OAuth Leaves Open

This is the distinction that trips up the most people, including experienced developers: OAuth 2.0 answers "what is this client allowed to access," not "who is this user." An OAuth access token proves the client was granted some scope of authorization; it says nothing standardized about the identity of the user who approved that grant, and it was never designed to.

Plenty of early implementations misused OAuth as a de facto login mechanism anyway, treating "the user successfully completed an OAuth flow" as equivalent to "the user is authenticated," which is a category error that led to real vulnerabilities.

What OIDC Adds

OpenID Connect (OIDC) exists specifically to close that gap. It is an identity layer built directly on top of OAuth 2.0, reusing OAuth's flows and roles but adding what OAuth deliberately left out: a standardized way to actually authenticate a user and learn who they are.

The mechanism it adds is the ID token, a JWT issued alongside (or instead of, depending on flow) the OAuth access token, containing a standardized set of claims specifically about the authentication event itself: who the user is, when they authenticated, which client the token was issued for, and how long the assertion is valid.

UserInfo Endpoint and Standardized Claims

OIDC also standardizes a UserInfo endpoint that a client can call, using the access token, to retrieve additional profile claims about the authenticated user. It defines a common, interoperable set of claim names (name, email, profile picture) so that different identity providers return user information in a consistent shape rather than every implementation inventing its own format.

This standardization is a large part of why "Sign in with Google" or "Sign in with Microsoft" buttons work consistently across countless unrelated applications: they are all speaking the same OIDC vocabulary underneath.

OAuth vs OIDC at a Glance

Put simply: if an application needs to know what a user is allowed to do against some API, that is an OAuth access token question. If it needs to know who is logging in, so it can create an account, display a name, or make an access decision based on identity, that is an OIDC ID token question. A well-built modern login integration typically issues both from the same flow.

Why OIDC Is Becoming the Default

This layering is also why OIDC has effectively become the default choice for new consumer-facing and increasingly enterprise SSO integrations, while SAML remains dominant in older or more XML-centric enterprise stacks. OIDC gives a standardized login answer using the same JSON/REST-friendly tooling most modern applications already use for everything else, without needing to also parse and validate XML.

JWT Structure and Validation

JSON Web Tokens (JWTs), defined in RFC 7519, are the token format underneath OIDC's ID tokens and very commonly used for OAuth access tokens as well, though the spec itself doesn't mandate JWT for access tokens specifically.

The Three Segments

Structurally, a signed JWT is three Base64URL-encoded segments joined by dots: header.payload.signature.

• Header. States metadata about the token itself, most importantly which signing algorithm was used.
• Payload. Carries the actual claims, the statements the token is making.
• Signature. Computed over the header and payload using the algorithm named in the header. It is what allows a relying party to detect if either segment has been tampered with after issuance.

Claims Inside the Payload

The payload's claims fall into a few categories. Registered claims are the standardized ones defined by the JWT spec itself so that different systems can interoperate:

• iss (issuer): who issued the token.
• sub (subject): who the token is about.
• aud (audience): who the token is intended for.
• exp (expiration time): after which the token must not be accepted.
• iat (issued-at time).
• nbf (not-before time).

Beyond these, tokens can carry public claims (registered in a public claims registry to avoid collisions) and private claims specific to a given deployment, like an internal role or department field an application defines for its own purposes.

What a Relying Party Must Validate

A JWT being well-formed and correctly Base64-decodable says absolutely nothing about whether it should be trusted. A relying party consuming a JWT is required to actively validate several things before accepting it, and skipping any one of them reopens a real, well-documented vulnerability class.

• Signature. Must be verified against the issuer's actual public key, using the algorithm the relying party itself expects, not simply whatever algorithm the token's own header claims to use. Blindly trusting the header's algorithm field is how the notorious "alg:none" and algorithm-confusion classes of JWT vulnerabilities have historically been exploited, where an attacker crafts a token claiming to use no signature, or a different algorithm than the server actually configured, hoping the validation logic accepts it anyway.
• Issuer (iss). Must match the specific IdP the relying party actually trusts.
• Audience (aud). Must match this specific application, exactly the same principle as SAML's AudienceRestriction, so that a token minted for one application cannot be replayed against a different one.
• Expiration (exp), and not-before if present. Must be enforced so an old or not-yet-valid token is rejected.

Why Each Check Matters

These checks are not optional extras; each one closes a distinct attack path. Skipping signature verification means accepting any token an attacker crafts, since nothing proves it came from the real issuer. Skipping issuer validation means a token from an unrelated or attacker-controlled identity source could be accepted as if it came from the trusted IdP.

Skipping audience validation means a legitimately issued token, minted for a completely different application, could be replayed against this one. Skipping expiration checks means a token stolen months ago still works today. In practice, real-world JWT validation bugs tend to come from exactly one of these checks being silently missing or misconfigured in a library or custom implementation, not from some exotic cryptographic break of the JWT format itself.

Signed, Not Encrypted

It also matters that JWTs are typically only signed, not encrypted, unless a deployment specifically uses the JWE (JSON Web Encryption) variant. That means the payload's claims are readable by anyone who intercepts the token, even though they cannot be modified without invalidating the signature.

Sensitive data should generally not be placed in JWT claims for exactly this reason; the signature protects integrity, not confidentiality.

Real Federation Attacks

Golden SAML: Forging the IdP's Signature

Golden SAML is the signature attack against SAML-based federation, and it earned its name and its notoriety through the SolarWinds/SUNBURST campaign attributed to APT29, publicly disclosed in December 2020. The technique itself was first documented earlier, by CyberArk researchers Shaked Reiner and Nir Yehoshua in 2017, but it was the SolarWinds campaign that made it a household name in security circles.

The attack targets the single most trusted piece of material in the entire SAML model: the IdP's private signing key and certificate. An attacker who gains administrative access to on-premises federation infrastructure, historically Active Directory Federation Services (AD FS) has been the most documented target, and steals that signing key can forge SAML assertions entirely offline, for any user, with any attributes or permissions, without ever touching the real IdP's login flow or triggering an actual authentication event.

Because the forged assertion carries a mathematically valid signature from the legitimate signing key, it is cryptographically indistinguishable from a real assertion, which is exactly what makes it so dangerous: it bypasses password checks and MFA entirely, since neither of those ever get evaluated when the assertion is forged directly. MITRE ATT&CK tracks this technique under Forge Web Credentials: SAML Tokens (T1606.002).

In the SolarWinds campaign, this technique specifically enabled the attackers to pivot from a compromised on-premises environment into cloud services like Microsoft 365, by forging SAML assertions that those cloud services trusted as legitimate.

Silver SAML: The Cloud-Native Variant

A related, newer technique called Silver SAML targets cloud-native identity providers rather than on-premises AD FS, and has been documented as capable of evading some of the specific detections built around the original Golden SAML pattern, though the underlying idea, forging assertions using compromised signing material, is conceptually similar.

OAuth's Attack Surface: Redirects and Replay

OAuth's attack surface looks different because the trust model is different, but the underlying theme, abusing a legitimate flow rather than breaking cryptography, is consistent.

• Open redirect / redirect_uri abuse. A well-documented, recurring class of real OAuth vulnerability. If an authorization server validates a client's redirect_uri loosely, for instance only checking that it starts with an allowed domain rather than matching it exactly, an attacker can register or find an open redirect on that same trusted domain and chain it to forward the authorization code or token, appended to the URL, straight to an attacker-controlled server. Because the redirect_uri parameter passed the authorization server's (weak) validation, the victim's browser dutifully carries the sensitive authorization code along for the ride. This is exactly why current OAuth security guidance insists on exact string matching for registered redirect URIs rather than prefix or domain-only matching, and why PKCE is recommended broadly, since even a stolen authorization code becomes far less useful to an attacker who does not also have the matching code verifier.
• Token replay. An access token or ID token intercepted through a compromised network, a logged referrer header, a browser history leak, or a server-side logging mistake can be reused by an attacker as long as it remains valid, if the resource server or relying party is not additionally checking things like token binding, expected audience, or unusual usage patterns. Short token lifetimes and refresh token rotation exist specifically to shrink the window in which a replayed token remains useful, and proper audience validation, covered in the JWT section above, is what stops a token issued for one relying party from being successfully replayed against a different one.

Why These Attacks Work

What ties Golden SAML and these OAuth issues together conceptually is worth naming directly: none of these attacks break the underlying cryptography of SAML, OAuth, or JWTs. They succeed by targeting the trust boundary around the protocol instead, stolen signing keys, loosely validated redirect URIs, tokens that outlive their usefulness, or relying parties that skip a validation step they were supposed to perform.

That is precisely why understanding the protocol mechanics from the earlier sections in this chapter matters for a SOC analyst or IR responder. Recognizing that Golden SAML requires prior administrative compromise of the IdP infrastructure tells you it is a late-stage, high-severity finding, not an isolated event, and recognizing that an OAuth redirect_uri validation gap is the actual root cause of a token-theft incident tells you exactly what configuration needs to be fixed, not just which token needs to be revoked.

Federation in the Real World

Who Runs Identity in Practice

The concepts in this chapter are not academic. A handful of identity providers dominate real enterprise deployments, and recognizing them by name matters because you will see them constantly in log sources, incident reports, and job postings alike. None of these vendors invented the underlying protocols; they are implementations of the same open standards, SAML 2.0, OAuth 2.0, and OpenID Connect, competing primarily on integration breadth, policy tooling, and user experience.

• Okta. One of the most widely deployed dedicated identity providers, supporting both SAML and OIDC integrations across thousands of pre-built application connectors.
• Microsoft Entra ID (formerly Azure Active Directory). Deeply embedded in any organization already running Microsoft 365 or Azure, supporting SP-initiated flows for both SAML and OIDC applications as well as IdP-initiated flows for SAML apps specifically.
• Google Workspace. Serves the same role for organizations built around Google's productivity suite.
• Ping Identity. Common in larger, more security-mature enterprises, particularly ones with complex legacy SAML estates alongside newer OIDC deployments.

Why the Names Matter for Log Analysis

Recognizing these names in practice matters for a specific reason: log sources and incident narratives will reference them constantly. An alert about anomalous Okta sign-in activity, a Microsoft Entra ID Conditional Access policy blocking a login, or a Sigma rule looking for suspicious AD FS token-signing certificate access are all directly downstream of the concepts in this chapter.

Understanding what a SAML assertion actually contains makes an Entra ID sign-in log immediately more legible. Understanding OAuth's redirect_uri validation makes an "unusual OAuth grant" alert something you can actually reason about instead of a term you pattern-match on faintly.

Connecting Back to Zero Trust

This chapter also connects backward and forward across the module in a specific way. Chapter 2's Zero Trust section described continuous, context-aware verification replacing implicit network trust; identity federation is the plumbing that makes that continuous verification practical at scale, since Conditional Access and similar policy engines are built directly on top of the IdP's authentication events described in this chapter.

A device-compliance check gating access under Zero Trust is typically evaluated at the exact moment the IdP is issuing a SAML assertion or OIDC ID token, not as some separate bolted-on system.

Where This Goes Next

Later modules in this platform, particularly cloud security content, will build directly on this chapter rather than re-explaining it. Cloud IAM federation (letting an on-premises identity assume a role in AWS or Azure without a separate cloud-only password), workload identity federation for CI/CD pipelines, and B2B guest access models all reuse the exact SAML/OIDC/JWT mechanics covered here, just pointed at cloud resources instead of SaaS applications.

Having this chapter's vocabulary solid, assertion versus token, IdP versus SP, authentication versus authorization, signature versus trust, is what makes those later, more cloud-specific topics click quickly instead of feeling like an entirely new subject.