SAML vs. OIDC: Federation Protocol Fundamentals
Concept
Federated identity lets a user authenticate once with a trusted Identity Provider (IdP) — an enterprise's Okta/Entra ID/Ping tenant — and be recognized by many downstream Service Providers (SPs) without re-entering credentials at each one. Two protocols dominate how that trust is expressed: SAML 2.0 and OpenID Connect (OIDC). Both solve the same problem — the IdP asserting "this is who the user is" to an SP — but come from different eras and carry different assumptions baked into their wire format.
SAML is XML-based and browser-redirect-driven: the SP redirects the user to the IdP, the IdP authenticates them and POSTs back a signed XML assertion (containing the user's identity and attributes) via the browser, and the SP validates the assertion's signature against the IdP's known certificate before establishing a session. Setup is manual metadata exchange — each side registers the other's entity ID, Assertion Consumer Service (ACS) URL, and signing certificate, typically via an XML metadata file exchanged once at integration time.
OIDC is a thin identity layer on top of OAuth 2.0, using JSON and REST instead of XML and SOAP-era conventions. The IdP exposes a .well-known/openid-configuration discovery document listing its endpoints and public signing keys; the SP fetches that once and self-configures, rather than hand-wiring metadata. Authentication produces a signed JWT id_token instead of an XML assertion, delivered through the standard OAuth Authorization Code flow. Because it's built on OAuth, an OIDC login can also mint an access token in the same flow, giving the app both "who is this user" and "what can this app do on their behalf" from one round trip.
Tradeoffs
| Dimension | SAML | OIDC |
|---|---|---|
| Wire format | XML, SOAP-era conventions | JSON, REST |
| Setup | Manual metadata exchange (entity ID, ACS URL, certs) per IdP | Discovery document — client self-configures from one URL |
| Identity artifact | Signed XML assertion, browser-POSTed | Signed JWT id_token |
| Mobile / native app fit | Poor — assumes a full browser redirect/POST flow | Strong — designed with mobile/SPA flows (PKCE) in mind |
| Enterprise IdP support | Near-universal — the default enterprise SSO expectation | Growing fast, but some legacy enterprise IdPs only speak SAML |
| Combined authz | None — SAML is authentication-only | Native — OIDC rides on OAuth, so authorization can come free |
The practical tradeoff isn't "which protocol is better" in the abstract — it's who's on the other end. A B2B SaaS product selling into large enterprises will keep meeting IdPs (older Active Directory Federation Services deployments especially) that only support SAML, regardless of how much cleaner OIDC's discovery-based setup is. A consumer-facing or mobile-first product integrating with modern IdPs (Google, Okta, Auth0 as customer-facing providers) gets a materially simpler integration with OIDC. Most mature enterprise SaaS products end up supporting both — OIDC for social login and modern IdPs, SAML for legacy enterprise customers who will not migrate their IdP just to satisfy one vendor's login page.
When to use / when not to
- Default to OIDC for any new integration where the identity provider supports it — self-configuring discovery, JSON tooling, and native mobile/SPA support make it materially less integration work than SAML.
- Support SAML specifically when a target enterprise customer's existing IdP only exposes SAML — this is a sales/procurement requirement more often than a technical preference, especially for regulated industries with older federation infrastructure.
- Don't build a custom SP-side identity bridge that translates one protocol into the other by hand unless there's no alternative; both protocols have mature, audited libraries, and hand-rolled assertion/token validation is a well-trodden path to a signature-verification bug.
- Don't assume "we support SSO" is a single checkbox — if the product serves both consumer and enterprise segments, budget for supporting both protocols rather than picking one and hoping every future enterprise customer's IdP matches it.
Common pitfall
Trusting an assertion or token without independently re-verifying its signature, issuer, and audience on every request — not just at initial login. A SAML assertion replayed outside its validity window, or an id_token accepted without checking that its aud claim matches this specific SP (not some other client of the same IdP), lets an attacker who intercepts or is issued a token for a different purpose reuse it somewhere it was never meant to be valid. Both protocols specify these checks explicitly; skipping them because "the library probably handles it" is the actual source of most real-world SSO integration vulnerabilities, not a flaw in either protocol's design.
Engineering Lens
The question that actually matters in a design review isn't "SAML or OIDC" — it's "which IdPs must this system federate with, and does that population actually support the protocol we'd prefer." Enterprise identity decisions are constrained by the customer's existing infrastructure far more than by engineering taste; a team that picks OIDC-only because it's the cleaner spec, then discovers their first major enterprise deal requires SAML, has turned a protocol preference into a sales blocker. The mature answer is usually an identity abstraction layer (or a managed identity platform like Auth0/WorkOS) that speaks both protocols to the outside world and normalizes to one internal user-identity representation — isolating the rest of the application from which federation protocol a given customer's IdP happens to use.