The moment you add "enterprise SSO" to your roadmap, you hit a fork: SAML or OIDC? SAML is the incumbent — the XML-based protocol that's run corporate single sign-on since 2005, and the one enterprise procurement checklists still ask for by name. OIDC is the modern option, built on OAuth 2.0, speaking JSON and JWTs instead of XML. Both let a user sign in once at their company's identity provider and access your app.

The conventional answer is "support both." That's not wrong, but it buries two things worth knowing before you build: a run of 2025 vulnerabilities that exposed how fragile SAML's security model is in practice, and a fact most Indian B2B teams get backwards — their customers' identity providers already speak OIDC, so you may need far less SAML than the checklist implies. Here's how to actually decide.

The 30-second difference

SAML 2.0 — an OASIS standard from 2005. The identity provider (IdP) sends the service provider (SP) an XML assertion, signed with XML Signature, usually via a browser form POST. Mature, ubiquitous in large enterprises, XML all the way down.
OIDC — OpenID Connect, an identity layer on top of OAuth 2.0. The IdP issues a JSON Web Token (the ID token), signed and verified with JWKS. Built for the web, mobile, and SPAs from day one.

Same job — federated single sign-on — different era and different data format. That format difference turns out to matter more than it sounds.

Why OIDC wins on new builds

For anything greenfield, OIDC is the easier and safer default:

JSON/JWT beats XML for everything you'll actually do — parsing, debugging, logging. A JWT is three base64 segments; a SAML assertion is a wall of namespaced XML.
Native to mobile and SPAs. OIDC was designed for the redirect-and-token world modern apps live in. SAML's browser-POST model is awkward outside server-rendered web apps.
Smaller, better-understood attack surface. Validating a JWT is a well-trodden path with a clear set of rules. XML signature validation is, as 2025 made painfully clear, a minefield.

The 2025 SAML security wake-up

XML Signature has a structural weakness: the part of the document that gets signature-verified and the part that gets read as the assertion are resolved by parsing the same XML — and if two parsers disagree about that XML, an attacker can slip a forged assertion past the check. This class of bug (signature wrapping, parser differentials) has haunted SAML for over a decade.

In 2025 it bit hard. Security researchers demonstrated parser-differential attacks that bypass SAML authentication entirely — "sign in as anyone" — including the widely used ruby-saml library (CVE-2025-25291 / CVE-2025-25292), where the signature-verification parser and the assertion-reading parser could be made to see different documents. The takeaway isn't "ruby-saml is bad"; it's that SAML's security depends on XML-canonicalization subtleties that are genuinely hard to implement correctly, and the failure mode is total — full authentication bypass. OIDC's JWT signing avoids this entire category: there's one canonical thing being signed, verified the same way every time.

This doesn't make SAML unusable — mature SP libraries and IdPs handle it — but it does mean that building new SAML support yourself is taking on a famously sharp-edged security responsibility. OIDC is much harder to get catastrophically wrong.

But SAML isn't going anywhere

None of this retires SAML. Large and regulated enterprises standardized on it years ago; their identity teams run it fluently; some older on-prem IdPs (legacy ADFS, certain Ping deployments) speak SAML first. And enterprise procurement checklists list "SAML SSO" as a hard requirement, sometimes without anyone checking whether OIDC would do. If you sell into the Fortune-500-of-India tier, you will eventually be asked for SAML, and "we only do OIDC" can lose the deal.

So the honest position is: OIDC for new builds, and SAML when the buyers you're chasing demand it. The question is when that is — and for Indian B2B, it's later than most teams assume.

The Indian B2B reality most teams get backwards

Here's the fact that changes the build order: most Indian B2B customers' workforces sign in through Google Workspace or Microsoft 365 — and both expose OIDC. When your customer's employees are on Google or Microsoft, you can offer them enterprise SSO over OIDC today, with none of SAML's XML and none of its signature-validation risk.

True SAML demand surfaces at a specific point: large, regulated Indian enterprises — banks, ITES majors — closing high-ACV deals, where the customer's identity stack predates OIDC or their security team mandates SAML by policy. That's a real and valuable segment, but it's not your first ten enterprise customers. Building SAML before you've lost a deal without it is optimizing for a problem you don't have yet, while taking on the security surface above.

How to choose

Greenfield SSO, SMB-to-mid-market customers → OIDC. It covers Google Workspace and Microsoft 365 (i.e. most of your buyers), it's simpler, and it sidesteps the SAML signature-validation risk.
Selling into large/regulated enterprises → you'll need SAML eventually; plan to add it (or integrate a SAML gateway) when a concrete deal requires it — not speculatively.
Either way → keep an audit trail of who signed in, via which IdP and protocol. Under DPDP, being able to show how a user was authenticated is part of the accountability story, and it's the kind of record enterprise security reviews ask for too.

How NamoID approaches it

NamoID is OIDC-native: it's a single OIDC issuer, and because Google Workspace and Microsoft 365 both speak OIDC, that already covers enterprise SSO for the large majority of Indian B2B customers — with an audit trail of every federated login built in. SAML, for the large-enterprise deals that genuinely require it, is on the path rather than something we ask you to bolt on speculatively. The point is to give you the protocol your customers actually use now, and the heavier one when a deal makes it worth it — not to make you carry SAML's complexity before then.

FAQ

Is SAML insecure? Not inherently, but its XML-signature model is hard to implement correctly, and 2025 saw full authentication-bypass CVEs from parser differentials. Use mature libraries; don't hand-roll it. OIDC avoids the whole class.

Can OIDC do everything SAML does for SSO? For the common cases, yes — and since Google Workspace and Microsoft 365 expose OIDC, it covers most enterprise workforces. SAML remains relevant for enterprises whose IdPs or policies require it.

Should I build SAML now? Only if a deal needs it. For most Indian B2B, OIDC covers your customers today; add SAML when you're selling into enterprises that mandate it.

What about SCIM? SCIM is provisioning (creating/deprovisioning users), separate from SSO (authentication). Enterprises often want both; they're complementary, not alternatives.

Pick the protocol your customers actually use

For new builds, OIDC is the right default: simpler, mobile-native, and free of the XML-signature failures that produced 2025's "sign in as anyone" bugs. SAML still matters for large regulated enterprises — but for most Indian B2B, whose teams live in Google Workspace and Microsoft 365, OIDC already is enterprise SSO.

NamoID gives you that OIDC-native issuer with a federated-login audit trail today, and a path to SAML for the deals that demand it. If you're adding enterprise SSO, start with what your customers already speak.