BIPI
BIPI

SAML vs OIDC in 2026: Picking the Right Protocol for the Right App

Cybersecurity

SAML still wins enterprise SSO conversations because procurement says so. OIDC wins modern app integrations because developers say so. Most serious organizations end up running both, and the configuration drift is where the bugs live.

By Arjun Raghavan, Security & Systems Lead, BIPI · October 16, 2024 · 6 min read

#saml#oidc#identity#sso

We get the SAML vs OIDC question about once a month. The honest answer is almost always: both, depending on the app, with a single IdP that supports both protocols natively and a unified policy layer above them.

But the question deserves more than a one-liner because the protocol choice does affect security posture, audit trail granularity, developer experience and what your enterprise customers will demand of you.

Where SAML still wins

Procurement-driven enterprise SSO. If you sell SaaS to Fortune 500 customers, their security team will ask for SAML 2.0 with SP-initiated and IdP-initiated flows. That requirement has barely shifted in a decade. Building OIDC-only puts you out of contention for half your enterprise pipeline.

Long-lived browser sessions to internal apps where the redirect dance is not a problem. SAML is verbose, XML-based, signed at multiple layers. The verbosity is a feature for auditors. Every assertion is self-contained, the signature chain is clear, the whole thing serializes cleanly into a SIEM.

Where OIDC wins

Mobile apps, single-page apps, anything with API-driven token refresh. SAML was designed for browsers. OIDC was designed for the modern app stack and it shows. Token sizes are smaller, the flows handle native apps gracefully, the access token plus refresh token model maps cleanly to API authorization.

Microservice-to-microservice authorization. OIDC plus OAuth 2.0 with PKCE and short-lived JWTs is the right shape for that traffic. Trying to do it with SAML assertions is a category error.

85%
of enterprise SaaS RFPs still require SAML
12x
typical assertion size: SAML vs OIDC ID token
2
protocols every serious IdP must speak

The dual-protocol IdP setup

Okta, Auth0, Microsoft Entra and Ping all support both. The trap is not in the IdP, it is in the policy consistency. We have audited deployments where the SAML SSO rules required MFA but the OIDC flow for the same user did not, because the policies were configured by different teams six months apart.

  • One policy engine, one rule set, applied at the protocol-agnostic layer of your IdP.
  • Same MFA requirements regardless of protocol. Auditors will ask. Be ready.
  • Unified session timeout configuration across both flows.
  • One audit pipeline that normalizes SAML assertions and OIDC tokens into the same event schema.

What enterprise customers actually require

If you are selling to enterprises, your customers will ask for SAML 2.0 with attribute mapping flexibility, just-in-time provisioning, and SCIM for lifecycle. They will rarely ask for OIDC explicitly. They might ask for SCIM 2.0, which works fine with either protocol underneath.

Build SAML support to win the deal. Build OIDC support because your engineering team will thank you and your modern app integrations will work better. Then build SCIM on top because nobody wants to manually provision users in 2026.

The protocols are not in competition. They serve different parts of the same architecture. The mistake we see most often is teams picking one for ideological reasons and then bolting on the other badly when reality forces the issue. Pick both upfront. Configure them consistently. Move on to harder problems.

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