BIPI
BIPI

SAML or OIDC: Stop Picking the One You Already Know

Cybersecurity

SAML and OIDC solve overlapping problems with different tradeoffs. Picking the wrong one creates years of integration debt. Here's the technical comparison and the decision rules we use when architecting identity federation.

By Arjun Raghavan, Security & Systems Lead, BIPI · January 31, 2024 · 7 min read

#saml#oidc#identity-federation

Every identity architecture review I've done in 2023 contained the same conversation. The team built SAML because their previous IDP was SAML. The new SaaS vendors only support OIDC. They now run a SAML-to-OIDC bridge that nobody understands, and the next migration is two years away. SAML versus OIDC is a permanent decision masquerading as a temporary one.

What They Actually Are

SAML 2.0 is a 2005 OASIS standard built around XML, signed assertions, and a browser-redirect flow. The identity provider (IDP) signs an XML document (the SAML assertion) and posts it to the service provider (SP) via an HTML form. The SP parses the XML, verifies the signature, and reads attributes.

OIDC is a 2014 standard built on top of OAuth 2.0. The IDP returns an ID token (a JWT) and optionally an access token, signed with JWK keys retrieved from a /.well-known/jwks.json endpoint. The flow uses HTTP redirects and JSON. Mobile and SPA apps are first-class citizens, not afterthoughts.

Where Each Wins

SAML wins where you need rich attribute statements with structured data, where the SP is an enterprise app expecting SAML out of the box (Workday, ServiceNow, legacy on-prem apps), and where regulatory frameworks specifically reference SAML (some government and healthcare contexts).

OIDC wins for modern web apps, mobile apps, and SPAs, for APIs (the related OAuth 2.0 access token model fits API authorization natively), and for any architecture that needs both authentication and authorization on the same primitives.

Decision Rules

  • New SaaS integration where both options exist: pick OIDC
  • Mobile app needs auth: OIDC with PKCE; SAML is a poor fit on mobile
  • API needs delegated authorization: OIDC plus OAuth 2.0; SAML doesn't have a clean API token story
  • Legacy enterprise app, IDP integration only via SAML: SAML
  • Workforce IDP federating to many SaaS: support both at the IDP layer (Okta, Entra ID, PingFederate all do this)

The pattern that keeps options open: use a workforce IDP that speaks both protocols natively. Configure new SaaS integrations as OIDC. Configure legacy integrations as SAML. When a legacy app supports OIDC, migrate. The IDP becomes the abstraction layer, not your application code.

Pitfalls That Ship to Production

SAML XML Signature Wrapping (XSW) attacks are 15 years old and still ship in production code. Custom SAML implementations frequently fail to verify which element the signature actually covers, allowing an attacker to inject an unsigned assertion alongside a signed one and confuse the parser. Use a well-maintained library (python3-saml, OneLogin's SAML toolkits, Spring Security SAML2) and don't hand-roll XML parsing.

OIDC ID token confusion: ID tokens are for authentication; access tokens are for authorization. Many teams use the ID token as an API bearer token because it's convenient. The result is that resource servers validate tokens issued for a different audience, and ID tokens leak from logs as if they were access tokens. Read RFC 8252 (Native Apps) and the OIDC core spec section 2 on ID token claims. The aud claim is the contract; enforce it.

SAML clock skew: assertions have NotBefore and NotOnOrAfter timestamps with tight windows. NTP drift on the SP causes intermittent auth failures that look like flaky network issues. Run chronyd on every SP and configure 60-120 seconds of allowed skew in the validation library.

Hybrid Deployments

Some apps need both. Workday integration for HR data and customer login via a SPA on the same domain. Okta and Entra ID both support running SAML and OIDC apps off the same IDP user store with the same authentication policies. Sessions are shared across protocols, so a user who signed in via OIDC for the customer SPA doesn't need to re-authenticate for SAML to Workday.

The trap is attribute mapping drift. SAML attributes use friendly names like "email" and "groups". OIDC claims have specified names like "email" and "groups" too, but the mappings to the underlying directory attributes can diverge. We audit a client every quarter who finds that their OIDC apps see a different employeeId format than their SAML apps for the same users. Pick canonical attribute definitions in your directory and map both protocols to the same source fields.

What This Looks Like in Three Years

OIDC continues to take share from SAML for new integrations. SAML doesn't go away, too many enterprise apps still ship SAML-only. The realistic architecture by 2025: most workforce IDPs broker between an OIDC-first new world and a SAML-flavored legacy. Build the IDP layer well now, because it's the part you'll lean on hardest as the protocol mix shifts.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.