SAML vs. OIDC for Enterprise SaaS Single Sign-On

Enterprise SSO is a multibillion-dollar market in 2026, headed toward well over ten billion dollars by 2034. If you sell software to enterprise accounts, you eventually have to pick a side in the SAML vs. OIDC fight, whether you meant to or not. A prospect's IT admin emails asking "do you support SAML 2.0?" and you say yes, because you looked it up an hour ago and prayed. The bigger question sitting underneath that one: which protocol, why, and what happens when the next prospect asks for the other.

I've watched founders treat this like old tech versus new tech. It isn't. SAML and OIDC came out of two different eras of thinking about identity, and both are still doing real, unglamorous work in production right now.

What SAML was built to solve and why enterprises still depend on it

Rewind to the early 2000s. Enterprises had a real headache: employees logging into a dozen browser apps, each with its own password, each one a helpdesk ticket waiting to happen. SAML showed up to fix that. A user logs in once at a central identity provider, the IdP, and the IdP hands out a signed XML document (called an assertion) telling every other app "yep, this is really them." The app on the receiving end, the service provider, never sees a password. It just trusts the signature and moves on.

XML wasn't a random pick, by the way. SOAP, WS-*, XSLT, that whole stack was standard operating procedure inside big companies back then. SAML just slotted into tooling people already had running on the floor.

A few things it got right from day one, and still does well: it carries rich detail, role, department, clearance level, group membership, all bundled into one signed document. It scales as hub-and-spoke, one IdP vouching for a user across dozens of service providers once trust gets set up. And it leaves a paper trail that Splunk parsers and custom XML detection rules were basically built around. It also supports RelayState, so after login a user lands on the exact page they asked for instead of a generic dashboard. Sounds small. It's a huge deal if your product does deep links, and I've seen support tickets pile up fast when someone strips that feature out by accident.

The SAML authentication market was worth over a billion dollars in 2024, growing at a strong projected compound annual rate through 2033. That's not the curve of something dying. That's the curve of something enterprises are stuck with, in the best sense of the word stuck.

One limitation nobody's fixing anytime soon: SAML was designed with a browser in the room. Mobile apps and native clients didn't exist when the spec was drafted, and it shows every time someone tries to bolt SAML onto a phone.

How OIDC was designed differently from the ground up

OpenID Connect Core 1.0 shipped February 25, 2014, more than a decade after SAML, built on a completely different foundation: OAuth 2.0. OAuth already handled authorization, letting an app touch a user's data on some other service. OIDC just added an identity layer on top, an ID token, and called it a day.

The design choices tell the whole story if you sit with them. Tokens are JWTs, compact JSON objects any modern web framework parses without dragging in an XML library. Transport runs through the OAuth 2.0 Authorization Code Flow, so tokens get picked up from a token endpoint instead of riding around in a browser URL or a form post. PKCE (RFC 7636, added in 2015) locks the authorization code to the original request, which matters a lot for mobile apps and single-page apps that can't keep secrets safe to begin with. There's also a discovery document sitting at a fixed URL, /.well-known/openid-configuration, that lets a client auto-configure itself by fetching one file instead of trading metadata by hand over email.

Because OIDC grew out of OAuth, it inherited API-native thinking from birth. The access token a user gets can turn around and authorize a call to your backend directly. No separate step bolted on afterward.

Worth a mention, though it's easy to miss: OpenID Federation hit its Final Specification in February 2026, giving OIDC a multilateral trust model, where many parties trust each other through a shared framework instead of pairwise agreements. That used to be SAML's home turf, exclusively. The gap is closing. Slowly, but it's closing.

SAML federates identity through signed documents. OIDC delegates identity through token flows built for apps that talk to APIs.

Where the two protocols diverge in practice: token format, transport, and onboarding friction

Put the tokens side by side and the philosophy jumps out immediately. A SAML assertion is a signed XML document, often several kilobytes, packed into a rigid schema. An OIDC ID token is a compact JWT carrying a handful of standard fields (sub, iss, aud, exp, nonce) plus whatever custom claims you tack on. One is a filing cabinet. The other's a sticky note that happens to be cryptographically signed.

Transport differs too, and it's not a minor detail. SAML moves an assertion through an HTTP redirect (compressed into the URL), an HTTP POST (base64 inside a form), or an artifact binding where the assertion never touches the browser and gets fetched later over a SOAP back-channel. OIDC just swaps a code for a token at an endpoint. The ID token and access token never show up in a URL bar, and PKCE makes an intercepted code worthless anyway.

Onboarding is where the actual pain lives, though. Set up a new SAML connection and you're manually swapping entity IDs, Assertion Consumer Service URLs, and X.509 certificates with the customer's IdP team. Every new enterprise logo becomes a fresh support ticket and a round of "can you re-send that metadata file" emails. I've sat in on calls where this took three weeks because the certificate expired between the first email and the second. OIDC skips most of that mess: client registration plus a discovery URL, and the app configures itself.

Mobile widens the gap further. SAML assumes a browser, so mobile support usually means an embedded webview jammed into your app. It works, technically, but it never feels quite right, and it carries its own security baggage nobody wants to inherit. OIDC's OAuth lineage means native mobile libraries already exist, and JWT access tokens drop straight into an API's Authorization header without ceremony.

Debugging follows the same split. SAML failures show up as XML parsing errors or signature validation failures, and untangling them takes tooling most engineers don't touch on a normal Tuesday. OIDC failures come back as JSON with a defined error code. Fixable in minutes instead of hours, most days.

The security trade-offs each protocol carries

NIST's SP 800-63C-4, published in 2025, treats SAML and OIDC as equally valid at every assurance level. The standards body isn't picking a winner here, so I won't pretend one exists either. But the vulnerability history tells its own story, and it's not a flattering one for SAML.

The recurring problem has a name: XML Signature Wrapping, XSW for short. The attack injects extra elements into a SAML response so the signature still checks out, but the service provider ends up reading identity data from an unsigned part of the document instead of the signed part. A forged assertion wrapped around a real signature. Like slipping a fake ticket stub inside a legitimate envelope and betting the usher doesn't look twice.

CVE-2024-45409 was the big one: a critical bug in the widely-used Ruby SAML library that let attackers log in as literally any user by forging a response. It hit GitLab, along with a pile of other Ruby-based service providers who probably found out the hard way. CVE-2024-8698 hit Keycloak's SAML signature validation and opened the door to privilege escalation. CVE-2025-47949 was a wrapping attack in samlify (pre-2.10.0) that allowed a full authentication bypass with nothing more than a legitimately signed XML document from the IdP, trivial once you know the trick. Then 2025 handed us two more in ruby-saml, one from a Libxml2 canonicalization error, one from namespace handling. The pattern repeats because XML parsers don't all agree on how to read the same document, and that disagreement is exactly where attackers set up camp. Patching one bad line doesn't fix this. It needs a rebuild of how these libraries canonicalize XML in the first place, and most vendors don't have the appetite for that.

OIDC's ID token, with explicit issuer, audience, and nonce fields, closes off a lot of the replay and injection tricks that plague XML assertions, assuming somebody implemented it correctly. It isn't bulletproof, either: tokens leaking through redirect URIs, sloppy audience validation, misuse of the old implicit flow, all real risks people still stumble into. But the attack surface is narrower and better documented, and PKCE shuts down authorization-code interception for public clients entirely.

Structural risk favors OIDC for anything new you're building today. But a well-run SAML stack beats a careless OIDC integration every single time, no contest. The lesson isn't "avoid SAML." It's "know what XSW looks like before you ship, and pick a library that patches fast when the next one shows up."

Choosing a protocol: the decision factors that actually matter

Your preference isn't the deciding factor here, and it never was. What your customer's IdP speaks is. The enterprise's identity stack picks the protocol for you; your job is just to show up ready for whichever one it turns out to be.

SAML wins when the prospect runs ADFS, Ping Identity, or another SAML-native IdP with nothing else configured. Same story if their security team's SIEM and audit pipeline already parse SAML assertions, since swapping that out quietly can break compliance workflows nobody thought to mention to you until it breaks. Regulated industries, healthcare, financial services, government, tend to have SAML audit trails baked into their compliance posture from years back, and ripping that out isn't happening on your timeline. If deep-linking via RelayState is a hard requirement, SAML just handles it, no extra engineering required.

OIDC wins when your customer is a modern SMB running Keycloak or Authentik with zero SAML infrastructure to speak of. Same if your product is API-first and downstream services expect JWT access tokens, since a SAML assertion is a dead end there. Mobile pushes you toward OIDC too, along with mixed user populations, employees, partners, consumers, where social login and varied identity sources need to coexist without a separate federation layer bolted on top.

Here's my rule of thumb for 2026: build new products OIDC-first unless you're plugging into a legacy IdP that only speaks SAML. For enterprise workforce SSO specifically, ship SAML first, OIDC second. None of this locks you in forever, though. Building one first doesn't lock you out of the other, and most products end up needing both eventually anyway, whether they planned for it or not.

Why 72% of enterprises run both protocols and what that means for SaaS builders

A 2025 analysis found 72% of enterprises now run multi-protocol SSO environments. SAML for legacy workforce apps, OIDC for the newer and mobile stuff, OAuth 2.0 handling API authorization underneath, all brokered through one identity platform sitting in the middle, trying to keep the peace.

Nobody planned this migration. It just happened, the way most infrastructure sprawl happens. Enterprises didn't rip out SAML and replace it with OIDC. They layered OIDC on top as new apps got built, and left the old SAML plumbing running because tearing it out wasn't worth the risk to anyone's weekend. Okta, Microsoft Entra ID, Ping Identity, OneLogin, JumpCloud, they all support both natively now, so the IdP absorbs the translation work and the enterprise never has to think about it twice. Okta holds a large share of the tracked standalone IAM market. Microsoft reported hundreds of millions of monthly active users on Entra ID as of its fiscal 2023 Q4 earnings. Sell to enterprise long enough, and you'll run into both platforms constantly. That's just the terrain.

The real danger in a hybrid setup isn't running two protocols. That part's fine. It's running them through two disconnected systems that don't share session state. Revoke a user's SAML session at the IdP, and they might still be walking around with a live OIDC token if the two stacks never talk to each other. Audit logs split across two independent systems need manual reconciliation too, which is its own headache in a regulated industry, and not the fun kind.

For SaaS builders, supporting both protocols isn't some far-off "enterprise scale" problem to punt on. It shows up the moment your second enterprise prospect happens to run a different IdP than your first one did. The real architecture question is how you handle both without ending up with two codebases, two sets of session logic, and two audit pipelines running in parallel forever, quietly duplicating each other's work.

The SSO tax and what it signals about how the market prices protocol support

Start with the procurement numbers, because they explain everything else here. SoftwareFinder's 2025 SaaS Security Report found a large majority of enterprise RFPs now require MFA plus SSO as part of the base plan, not a premium bolt-on, and a substantial share of buyers have disqualified a vendor outright for failing to produce verifiable credentials. SSO stopped being a nice-to-have a while back. It's table stakes before the conversation even starts.

And yet plenty of SaaS companies still gate SAML support behind their most expensive tier, often at a markup that would make a loan shark blush and maybe apologize. Industry folks call this the SSO tax, and there's a whole public catalog tracking it, sso.tax. As of June 2026 it lists around 150 vendors, 104 with a computable markup and 44 more just saying "contact sales," which is corporate speak for "we're going to make you negotiate for this, in a room, with coffee."

The spread is wild once you actually look at it. GitHub's SAML tier runs about a 425% markup over its base plan. Figma sits around 275%. Notion is comparatively gentle at roughly 88%, which almost feels like a courtesy at this point. Then you hit the outliers: Railway near 9,900%, Mixpanel around 4,065%. Read those numbers twice. They're not typos, and I checked.

What the tax really signals is a pricing bet: enterprise buyers will pay almost anything for SSO because procurement treats it as non-negotiable, not a feature anyone's excited about or shopping around for. That bet gets riskier every year OIDC lowers the engineering cost of supporting SSO in the first place. Once a protocol is cheap to build, cheap to onboard, and cheap to maintain, a 9,900% markup stops looking like smart pricing. It starts looking like an open invitation for a competitor to undercut you on the exact feature procurement refuses to skip.