SAML vs OIDC: Which SSO Standard Should You Support?

Sooner or later a B2B customer will ask for single sign-on, and you'll have to answer a question that sounds simple but isn't: SAML or OIDC? Both let a user log in with their company identity provider. They come from different eras and solve the same problem in very different ways. This article compares them so you can decide what to build.

The one-paragraph version

SAML (Security Assertion Markup Language) is the older, XML-based standard that dominates enterprise SSO — if a large company has an identity provider, it almost certainly speaks SAML. OIDC (OpenID Connect) is the modern, JSON-based identity layer built on top of OAuth 2.0; it's simpler, mobile- and API-friendly, and increasingly the default for new integrations. For enterprise SaaS, the pragmatic answer is often "support both," but the order you build them in depends on your customers.

How SAML works

SAML is built around a signed XML document called an assertion. The flow (SP-initiated, the common case):

The user's browser shuttles a signed XML assertion from the identity provider (IdP) to your app (the Service Provider, or SP). Your app validates the XML signature against the IdP's certificate and reads the user's identity and attributes from the assertion.

Characteristics: XML and XML-DSig signatures, certificate-based trust, browser-redirect/POST bindings, deeply entrenched in enterprise IT. Also notoriously fiddly — XML canonicalization and signature validation are a common source of subtle, dangerous bugs.

How OIDC works

OIDC adds an identity layer to OAuth 2.0. Instead of an XML assertion, the IdP issues a signed ID token — a JWT — alongside the usual OAuth tokens.

Because it's built on OAuth's Authorization Code flow with PKCE, OIDC inherits a modern, well-understood security model. The ID token is a JSON JWT verified against the provider's JWKS endpoint — the same verification you'd do for any RS256 token.

Side by side

The differences that actually cost you engineering time

The comparison table above is accurate and slightly useless, because none of those rows is what makes SAML expensive. Four things do.

Configuration is manual and per-customer. An OIDC integration can be bootstrapped from a single discovery URL: fetch /.well-known/openid-configuration, read the endpoints and the JWKS URI, done. SAML has no equivalent that anyone reliably uses. You exchange metadata XML — sometimes by URL, often by an IT administrator emailing you a file — and then you map attributes by hand, because the IdP will send the email address as http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress or urn:oid:0.9.2342.19200300.100.1.3 or just email, depending on the product and how it was configured. Every SAML customer is a small integration project. Budget for a support workflow, not just code.

Certificates expire, and nobody tells you. SAML trust is pinned to an X.509 certificate that typically lasts one to three years. When it rolls over, every assertion fails signature validation at once, and the customer's entire workforce is locked out on a Monday morning. OIDC's JWKS endpoint solves this by design: the provider publishes its current keys, clients refetch on an unknown kid, and rotation is invisible. If you support SAML, you need certificate expiry monitoring and proactive customer outreach as an actual feature — see key rotation for how much easier the JWKS model is.

Logout is a different problem in each. SAML has Single Logout (SLO), a protocol for propagating a logout across every service the user signed into. It is genuinely useful and genuinely unreliable — it depends on every participant being reachable and behaving, and partial failures are common enough that many providers quietly do not implement it. OIDC's front-channel and back-channel logout specs are cleaner but less universally supported. In practice, most teams end up treating logout as local to their own session and relying on short session lifetimes for the rest.

IdP-initiated flows have no request to correlate. In SAML, a user can start at their IdP's app dashboard and be POSTed straight into your app with an unsolicited assertion. There is no AuthnRequest you generated, which means there is no state or nonce to check — the standard CSRF protection simply is not available. This is why IdP-initiated SAML is a known weak spot: an attacker who can obtain a valid assertion for their own account can POST it into a victim's browser and silently log them into the attacker's account, setting up a classic login-CSRF. If you support IdP-initiated flow, you need replay protection on the assertion ID, tight NotOnOrAfter windows, and an interstitial confirmation before you attach the session to anything sensitive. OIDC's equivalent — the nonce bound to your original request — makes this class of problem structurally harder.

Provisioning is the other half of the ask

When an enterprise buyer says "we need SSO," they very often mean two things, and the second one is not authentication at all. SSO answers can this person log in. It does not answer does this person still work here, and it does not create their account before they first arrive.

That second half is SCIM — a REST-based provisioning protocol that lets the customer's identity system create, update, and deactivate users in your app directly. Without it, an employee who leaves the company can no longer log in via SSO, but their account, their API keys, and their group memberships all sit there untouched. Auditors notice this. With SAML alone you are relying on just-in-time provisioning — creating the user on their first successful assertion — which handles arrival but not departure.

The practical sequencing for most B2B products is: OIDC first because it is cheap, SAML when the first six-figure deal requires it, and SCIM when the first customer's security review asks how deprovisioning works. All three should sit on the identity model described in Designing Multi-Tenant Authentication — a user record that outlives any particular login method — and be enforced per organization as covered in SSO enforcement for B2B.

Which should you support?

• If your buyers are large enterprises, SAML is often non-negotiable — their IT department standardized on it years ago, and "do you support SAML?" is a procurement checkbox. Build SAML.
• If you're integrating with modern IdPs or building consumer/prosumer SSO, OIDC is simpler, safer to implement, and works cleanly across web, mobile, and APIs. Prefer OIDC.
• If you're a B2B SaaS scaling upmarket, you'll likely need both. A common path is to start with OIDC (easier, covers many providers) and add SAML when the first enterprise deal requires it.

Whatever you support, keep it decoupled from your core identity model. As covered in Designing Multi-Tenant Authentication, separating who the user is from how they authenticated means adding SAML or OIDC later is a new login path, not a rewrite of your user tables.

Security notes

• SAML: the danger zone is signature validation. XML signature-wrapping attacks are real; use a battle-tested library, validate the signature over the right element, and pin the IdP certificate. Never trust an unsigned or partially-signed assertion.
• OIDC: treat the ID token like any JWT — pin the algorithm, verify iss, aud, and exp, and check the nonce you sent. The JWT misuse failures apply directly.

Bottom line

SAML is the incumbent you support because enterprises demand it; OIDC is the modern standard you'll enjoy implementing and want as your default. Neither is going away soon. Design your identity layer so authentication method is pluggable, and you can add whichever your next customer needs without disrupting the users you already have.