Enterprise SSO: SAML vs OIDC, and How to Pick

Key takeaways

• SAML is the older XML-based protocol; OIDC is the modern JSON / OAuth 2.0-based protocol.
• Most enterprise IdPs (Okta, Entra, Ping, Google Workspace) support both; the customer's existing setup determines which you implement first.
• SAML still dominates enterprise install base; OIDC dominates new integrations.
• B2B SaaS should support both protocols at the per-Organization level, the customer picks.
• The CIAM choice matters: per-Org SSO connections with self-service IdP setup is the differentiator that turns SSO from a project into a configuration step.

What enterprise SSO is

The practical question for B2B SaaS isn't usually SAML versus OIDC philosophically, it's which the next contract requires first. The IT admin filling out the security questionnaire knows which protocol their IdP is configured for; the SaaS just needs to support both so it isn't the blocker.

SAML 2.0: the install base

SAML (Security Assertion Markup Language) was standardized in 2005. It is XML-based, request-and-response oriented, and the protocol most enterprise IdPs default to for application SSO. The exchange:

1. User clicks "Sign in with SAML" in the SaaS.
2. SaaS redirects to the IdP with a SAML authentication request.
3. IdP authenticates the user (password, MFA, etc.).
4. IdP redirects back to the SaaS with a signed SAML assertion.
5. SaaS verifies the assertion signature and creates / matches the user record.

SAML's strength is install-base coverage: every enterprise IdP supports it, every SAML-aware SaaS works with every other SAML-aware IdP, and procurement teams know what to ask for.

SAML's weakness is the developer experience: XML signing edge cases, attribute mapping ambiguity (emailaddress vs email vs mail), and the fact that the spec is dense enough that subtle bugs hide in many implementations. For new integrations, OIDC is materially less painful to debug.

OIDC: the modern integration

OIDC (OpenID Connect) is OAuth 2.0 with identity claims layered on top, JSON-based, well-understood by modern tooling, and easier to debug. The exchange:

1. User clicks "Sign in with [IdP]" in the SaaS.
2. SaaS redirects to the IdP's authorization endpoint with an OIDC request.
3. IdP authenticates the user.
4. IdP redirects back with an authorization code.
5. SaaS exchanges the code at the IdP's token endpoint for an ID token (a signed JWT containing identity claims) plus an access token.

For SaaS-to-IdP federation, OIDC is the preferred protocol for new integrations. Discovery (.well-known/openid-configuration) makes IdP setup near-trivial: paste a discovery URL, the SaaS auto-configures.

The catch: many enterprise IdPs treat OIDC as their secondary protocol, and procurement teams sometimes ask for SAML by name even when OIDC would work. B2B SaaS that implements only OIDC will lose deals where the customer's procurement requires SAML in writing.

Per-Organization configuration

The architectural decision that makes Enterprise SSO scalable is per-Organization configuration. Each customer's Organization in your B2B SaaS has its own IdP connection, its own attribute mapping, its own signing key, its own claim transformations.

This is what the right CIAM ships as a primitive. The wrong CIAM either ships SSO at the global tenant level (one IdP for the whole SaaS, unworkable for B2B) or expects you to roll per-Org SSO yourself on top of generic SAML / OIDC libraries.

The vendors that handle per-Org SSO cleanly: WorkOS, Frontegg, Auth0 (Enterprise Connections + Organizations), SSOJet, Scalekit. For these, adding a new customer's IdP is a configuration step. For others, it's an engineering project.

Self-service IdP setup

The next-level differentiator: the customer's IT admin can configure their own IdP without involving your engineering team. This is an embedded UI where the admin uploads their SAML metadata XML (or pastes their OIDC discovery URL), maps attributes to user fields, tests the connection, and ships it.

WorkOS, Frontegg, Auth0 B2B Organizations, and MojoAuth all ship this UX. Without it, every new enterprise customer's SSO setup requires a back-and-forth between your engineering and their IT, a meaningful tax on enterprise sales velocity.

Just-in-time provisioning vs SCIM

SSO authenticates the user. Provisioning creates the user record. The two patterns:

• Just-in-time (JIT) provisioning, auto-create the user record on first SSO login, populated from the SAML or OIDC assertion attributes. The user clicks "Sign in with SSO" and gets a usable account.
• SCIM Directory Sync, the IdP pushes user records to your SaaS via SCIM API as employees are added, updated, and removed. Required for proper deprovisioning at scale.

Most B2B SaaS uses JIT for first-login convenience and SCIM for ongoing lifecycle, especially deprovisioning. SCIM is the harder feature; JIT comes free with proper SSO implementation.

Implementation choices

The CIAM that ship Enterprise SSO best, supporting both SAML and OIDC, per-Organization, with self-service setup, JIT, and SCIM, are the same products that ship strong B2B SaaS identity overall: WorkOS, Frontegg, Auth0, MojoAuth, with SSOJet, Scalekit, and Kinde as newer entrants in specific niches.

For self-hosted, Keycloak and WSO2 Identity Server handle SAML and OIDC well at the protocol level but require theming work for the self-service IdP setup UX.