OIDC or SAML: which one you actually need

Every team building B2B software hits the same fork the first time a serious customer says "we need SSO." Two acronyms, OIDC and SAML, both claiming to be the answer, and an internet full of comparison tables that tell you SAML is "enterprise" and OIDC is "modern" and leave you exactly as stuck as before. Here's the version that actually helps you ship.

What they are

SAML is from 2005 and it is XML. An identity provider signs an assertion ("this is [e-mail], here are her groups") and posts it to your app, which checks the signature and logs her in. It was built for the browser and for workforce identity, in an era when "the enterprise" meant on-prem Active Directory and a SOAP stack. It is verbose, it is old, and it is absolutely everywhere inside large organizations, which is the one fact about it that matters to you.

OIDC is from 2014 and it is JSON and JWTs, sitting on top of OAuth 2.0. An identity provider issues an ID token your app validates. It was built for the modern web: SPAs, mobile apps, APIs, social login. It is cleaner, better specified for the things you actually build today, and the protocol most greenfield identity now speaks.

When each wins

The honest answer to "which should I build" is that you almost never get to choose. You build the one your customer's IT department picked, and they picked it long before they had heard of you.

• A customer on Okta, Entra ID, or Google Workspace can usually do either, and OIDC is the nicer path.
• A customer on an older ADFS, a legacy on-prem IdP, or a procurement checklist written in 2016 will hand you a chunk of SAML metadata and a calendar invite, and that is the end of the discussion.
• Your own first-party apps, your dashboard and your mobile client, want OIDC, full stop. You would never reach for SAML to log a user into your own React app.

So the field splits cleanly: OIDC for the modern and the first-party, SAML for "because the enterprise said so." Sell to enough enterprises and you will be asked for both. Not eventually. Repeatedly.

The gotchas, which is where building it yourself gets expensive

SAML's problem is that it is a signed-XML protocol, and signed XML is one of the most reliably dangerous things in applied cryptography. The ways to get SAML signature verification wrong are many and famous:

• Signature wrapping (XSW): an attacker moves the signed element and slips an unsigned, forged assertion where your parser actually reads. If you check the signature and read the assertion as two separate steps, you are probably vulnerable, and almost every first implementation does exactly that.
• Canonicalization and comment injection: the 2018 class of bugs where [e-mail]<!---->.evil.com canonicalizes one way for the signature check and another way for the string your code reads, so you cheerfully authenticate the wrong person. Real CVEs, multiple major libraries.
• The quieter ones: signing the response but not the assertion, accepting unsigned assertions, trusting the IdP-supplied issuer without pinning it, getting the assertion validity window wrong. Each is its own footgun, and each has been shipped to production by people who knew what they were doing.

OIDC is meaningfully saner, but it is not free of sharp edges. You still have to validate the right claims (iss, aud, exp, the nonce), use PKCE, refuse the long-dead implicit flow, and rotate and cache JWKS without rejecting a token signed by a key you have not fetched yet. The difference is that OIDC's traps are documented, JSON-shaped, and handled correctly by default in most libraries. SAML's traps are XML-shaped and have eaten security teams far better resourced than yours.

The real answer

"OIDC or SAML" is the wrong question, because the right answer for a B2B product is "yes." Your modern customers and your own apps want OIDC. Your enterprise customers will mandate SAML on a timeline you do not control. Build for one, and the third sales call breaks it.

What you actually need is a way to accept whichever protocol each customer brings, without standing up two stacks, two sets of metadata plumbing, and two independent chances to get signature verification wrong. The implementation is the cost. The choosing was never the hard part.

That is the part Authagonal takes off your plate. Every tenant gets SAML 2.0 with one-click metadata import and OIDC federation with the providers your customers already run, on the same login, with no per-connection fee for either. You do not implement XML signature verification, you do not babysit a JWKS cache, and you do not rebuild any of it when the next customer shows up speaking the other protocol. See what's included.