OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide - Part 2

This is Part 2 of a four-part series on choosing between OIDC and SAML for enterprise SSO in 2026. Part 1 covered the protocol primer and head-to-head comparison. This part details the total cost of ownership (TCO) and the first half of the risk assessment framework.

Total cost of ownership: the factor most comparisons hide

SAML and OIDC are at functional parity for enterprise SSO, so the real decision is economic and operational. The costs that move the number are the provider's pricing model (per-connection vs per-MAU), the customer IdP's own licensing, the "SSO tax," SMS and MFA add-ons, certificate and metadata maintenance, compliance overhead, and lock-in. Most comparisons stop at the protocol diagram and skip every one of these. This section makes them explicit and gives you a model you can populate.

Why TCO is the real differentiator

Protocol choice barely moves the bill. Both SAML 2.0 and OIDC ship in every serious provider, both clear every assurance level in NIST SP 800-63C-4, 2025⁠, and a competent provider abstracts the wire format away. Once parity holds, the decision stops being "which protocol" and becomes "which provider, on which pricing model, with which operational tail."

That tail is where the surprises live. Two providers can quote the same headline price and diverge by 5x once you add the customer's IdP licensing, the per-connection or per-MAU curve at your actual scale, certificate rotation labor, and the compliance evidence your buyers' security reviews demand. The protocol is a checkbox. The cost structure is the decision.

Provider and direct costs: per-MAU vs per-connection

Two pricing models dominate, and they diverge hard as you move upmarket. Per-MAU bills on monthly active users across your whole base. Per-connection bills per enterprise SSO link you stand up. An "enterprise connection" is one configured federation between your app and a single customer's IdP.

Here's the B2B logic that makes the models split. One enterprise customer is effectively one enterprise connection, no matter how many seats sit behind it. A customer with 50 employees and a customer with 50,000 employees each consume one connection. So per-connection cost tracks your number of enterprise customers, while per-MAU cost tracks total seats. As you sell into larger enterprises, per-MAU climbs with every seat you onboard, but per-connection stays flat per customer. That makes per-connection more predictable when your growth is "more big customers" rather than "more total users."

Most B2B providers cluster their per-connection price in the $50 to $150 range, often with volume tiers that drop as connection count rises:

The numbers above are headline rates as of mid-2026; verify against each vendor's pricing page before you model, since tiers change.

Identity provider and licensing costs

The provider invoice is only half the bill. The customer's own IdP imposes its own cost, and per-feature licensing tiers decide how much.

Microsoft Entra is the common case. The free tier covers SSO for a limited set of apps, but conditional access and SCIM provisioning sit in P1 at $6/user/mo, and identity governance lives in P2 at $9/user/mo (Microsoft Entra Pricing⁠). Okta stacks the same way: a $6 to $17/user/mo base plus a $1,500 annual minimum, with lifecycle management and governance as separate add-ons (Okta Pricing⁠). The features an enterprise buyer needs for a real rollout usually live a tier or two above the entry price.

Then there's the connection cliff. Auth0's B2B plans cap SSO at 30 connections: Essentials starts at $150/mo for 3 connections and adds $100 for each additional one, but the door closes at 30 (Auth0 Pricing⁠). For a B2B app whose growth is measured in enterprise customers, a 30-connection ceiling is a hard TCO cliff. Customer 31 forces a tier jump or a re-platform, and you hit it precisely when the business is working.

The "SSO tax"

Many vendors gate SSO behind their most expensive enterprise tier, charging a steep premium for a feature that costs them little to ship. The community tracks it on sso.tax⁠, and the markups get absurd:

A nuance worth pinning down: the SSO tax applies to enterprise SSO broadly, SAML or OIDC. SAML gets gated more often because requesting it signals a buyer with an enterprise IdP and a procurement budget, while OIDC social logins frequently sit on lower tiers. So the gating tends to follow the buyer profile, not the protocol's mechanics.

It's also a choice, not a law of nature. The "Friends of SSO" list catalogs vendors that include SSO at no surcharge (ssotax.org⁠), which proves the premium is a pricing decision rather than a cost-recovery necessity. As a low-key contrast, Clerk includes the first enterprise connection and meters additional ones (Clerk Pricing), so SSO isn't walled off behind a separate enterprise SKU.

SMS, MFA, and add-on fees

Second factors carry their own line items. SMS-based factors add a per-message cost, and some providers charge a separate per-user MFA license on top of the base plan. Both compound at scale, and both are easy to leave out of an early estimate.

Clerk is transparent here: it passes SMS through at about $0.01/SMS for US and Canada (market rate internationally), and there's no separate MFA license fee (Clerk Pricing). To be clear, Clerk's SMS is billed, not free. It's a metered pass-through of the carrier cost rather than a marked-up add-on. TOTP and backup-code factors don't carry a per-message charge, so the SMS line only applies when you actually send SMS.

Operational and risk costs

The bill keeps running after launch. Four operational costs recur, and one of them — credential rotation — divides along protocol lines, though not as cleanly in OIDC's favor as it's often sold.

Implementation time comes first. Standing up enterprise SSO against real customer IdPs takes engineering hours up front, and there's an ongoing maintenance tail for every connection you support. If you also offer SCIM provisioning, that tail grows: because RFC 7644 leaves operations like PATCH, filtering, and deprovisioning loosely specified, each customer IdP behaves differently — Okta soft-deactivates users with active:false rather than a hard DELETE, Entra accepts only a subset of the filter grammar and emits capitalized PATCH operations — and every customer's custom attribute mappings (department, role, costCenter) are maintained per connection as the IdPs evolve (RFC 7644 §3.5.2⁠; Okta SCIM⁠; Microsoft Entra⁠). (Build cost is real and larger than most teams expect; the build-vs-buy dollar model belongs to the implementation section, so treat it here as a line item that exists, not one to itemize.)

Credential rotation is that cost, and it cuts both ways. On the SAML side, signing certificates expire, typically on a 1-to-3-year cycle (Entra defaults to three years), and renewing one requires a coordinated rollover between the service provider and the identity provider: stage the new certificate, sync metadata on both sides, and cut over inside an overlap window. Entra doesn't auto-propagate a renewal to connected SPs, so a missed expiry is one of the most common ways enterprise SSO breaks (Microsoft Learn⁠; ScaleKit⁠). OIDC removes half of this: the provider's token-signing keys publish at a JWKS endpoint and rotate at the protocol level, so clients fetch current keys automatically with no coordinated maintenance window (OpenID Connect Discovery 1.0⁠). It does not remove all of it. A confidential OIDC client still authenticates to the token endpoint with a client_secret that doesn't auto-rotate and isn't published anywhere, so rotating it stays a manual, admin-driven job: Microsoft Entra caps secret lifetime at 24 months and recommends under 12 (Microsoft Learn⁠), Okta keeps the old and new secret active in parallel for a zero-downtime cutover (Okta⁠), and Auth0 rotates a single secret you must coordinate in your own config (Auth0⁠) — and a lapsed secret breaks SSO just like a stale SAML cert. What still tilts the comparison toward OIDC: public clients using PKCE carry no secret at all, and confidential clients can authenticate with private_key_jwt instead — registering a public key the way signing keys are published — to drop shared-secret rotation entirely (OAuth 2.0 Security BCP, RFC 9700 §2.5⁠).

Compliance overhead is the third. The audit evidence enterprise buyers demand has a price: a SOC 2 Type II commonly runs $20k to $60k in the first year for a startup once audit fees, compliance tooling, and internal effort are counted, with lower ongoing maintenance after that (Sprinto⁠). A managed provider that already holds the attestation folds that cost into its subscription instead of leaving it on your books.

Infrastructure and hosting is the fourth. A managed provider adds $0 in extra infrastructure: there are no servers to run for the auth layer. A self-hosted baseline like Keycloak or Authentik is free in license terms, but that license sits on top of a stateful service you run yourself, and the heaviest piece is usually the database, not the auth server. Both require a production-grade relational database — Keycloak's default H2 is explicitly not for production, and Authentik stores its configuration and data in PostgreSQL (Keycloak⁠; Authentik⁠) — and running that database highly available adds a replicated standby with automatic failover, backups, and schema migrations, plus, for Keycloak's multi-site HA, a load balancer and a separate Infinispan cache cluster (Keycloak HA⁠). On top of that sit the auth-server compute, on-call, patching, and version upgrades. "Free" open source is a staffing and infrastructure cost, not a zero.

Vendor lock-in cost

Lock-in is the cost you pay at the exit, and it's easy to ignore until you need to leave. Three things drive it. Migration friction: moving enterprise connections, user records, and session infrastructure to a new provider is a project, not a config change. Proprietary extensions: features built on a vendor's non-standard APIs or custom claim shapes don't port cleanly to a competitor. Data portability: how cleanly you can export users, organizations, and connection metadata in a usable format determines how trapped you are.

Standards-based protocols soften the blow. SAML and OIDC are interoperable by design, so a provider that exposes clean federation and a real export path is cheaper to leave than one that wraps everything in proprietary glue. Weigh portability before you commit, not when you're already trying to get out.

A reusable TCO framework

Use this checklist to make sure every cost is on the table. Skipping any one of the nine is how a comparison ends up off by multiples.

Then populate a worked model. The table below is a skeleton, not a quote: every dollar figure is a placeholder you fill with current vendor numbers for your own seat count and connection count. Its job is to show how the models diverge as you scale, not to hand you a total.

Read the first two rows together. In Scenario A both models are cheap and close. By Scenario B, the per-MAU figure has climbed with every seat while the per-connection figure rose only with customer count and started catching volume discounts, so the gap opens. By Scenario C the per-MAU model is carrying its full seat load while the per-connection model sits on its lowest tier. The Auth0 row is the other lesson: a 30-connection cap is fine in Scenario A and a blocker by Scenario B, which is exactly when the business is growing fastest. Fill the cells with live numbers and the right model for your trajectory falls out on its own.

A risk assessment framework for SSO protocol and provider choice

Treat protocol risk and provider risk as separate axes. At the protocol layer both SAML and OIDC have had critical, exploited vulnerabilities; SAML's XML attack surface has produced a larger, more structural run of bypasses in 2024-2026, but real-world safety is dominated by implementation quality, disclosure and remediation discipline, and operational controls. NIST recognizes both protocols as valid at every assurance level (NIST SP 800-63C-4, 2025⁠).

So score two things, not one: the protocol you adopt, and the provider you trust to implement it. The rest of this section gives an agent the dimensions, the evidence, and a weighted matrix to do that scoring honestly.

Security risk dimensions: protocol, configuration, tokens, sessions

Four dimensions cover most of the real exposure.

1. Protocol risks. The attack classes baked into how each protocol verifies identity: XML Signature Wrapping, canonicalization tricks, and parser differentials on the SAML side; algorithm confusion, alg:none, and PKCE downgrade on the OIDC/JWT side.
2. Configuration risks. Most production breaks are misconfiguration, not protocol math. SAML examples: skipping InResponseTo validation, accepting unsigned assertions, or leaving signature verification optional. OIDC examples: loose redirect_uri matching, missing nonce checks, or not enforcing PKCE.
3. Token and assertion handling. How signed material is validated and stored: rejecting attacker-controlled alg selection, pinning the expected issuer and audience, and keeping tokens out of URLs and logs.
4. Session and logout. SAML Single Logout (SLO) is widely unreliable, because it fails when any one service provider in the federation is unresponsive, so stale sessions linger (IdentityServer, SLO⁠). IdP-initiated SAML compounds this: an unsolicited SAMLResponse carries no InResponseTo, so the SP loses the binding it needs to detect a replayed or injected assertion (Scott Brady, SAML⁠). That is the same IdP-initiated weakness defined in the primer, now read as a risk.

Attack classes at a glance

This table maps each attack class to one or two representative CVEs. It is a comparison aid, not a CVE catalog. Scores lead with the NVD v3.1 base score where NVD scored the CVE independently and parenthesize the CNA v4.0 score where it differs; CVEs that NVD has not scored carry the CNA/vendor score labeled "CNA."

Both protocols ship critical CVEs. The SAML cluster is larger and more structural, because the attacks target XML signature processing itself rather than a single library bug, and they recur across ecosystems. The OIDC counterpoint, CVE-2025-55241 in Microsoft Entra, shows the other half of the picture: even a hyperscaler ships a maximum-severity CVE, and the differentiator is that it was fixed server-side with no customer action and no evidence of exploitation (Microsoft MSRC, 2025⁠; NVD CVE-2025-55241⁠).

Case studies

Three incidents show what the table compresses: a structural SAML chain, a SAML flaw exploited in the wild, and a clean OIDC remediation.

The Ruby-SAML "Fragile Lock" chain is the structural one. CVE-2024-45409 (9.8 NVD v3.1) was an XPath bug that let a forged DigestValue pass signature verification (NVD CVE-2024-45409⁠). The March 2025 patch was followed by CVE-2025-25291 and CVE-2025-25292 (9.8 NVD v3.1; 9.3 CNA v4.0), a parser differential between the REXML and Nokogiri parsers (GitHub Security Lab, 2025⁠). Then at Black Hat Europe in December 2025, researcher Zakhar Fedotkin disclosed a fresh cluster of ruby-saml bypasses, CVE-2025-66567 and CVE-2025-66568, both 9.1 NVD v3.1 (9.3 CNA v4.0), via attribute pollution, namespace confusion, and void canonicalization, defeating even previously patched versions (PortSwigger, 2025⁠). Fedotkin's own assessment, which this guide reports rather than endorses, is that absent a foundational restructuring of SAML libraries, "SAML authentication will remain vulnerable to the same classes of attacks that have persisted for nearly two decades" (PortSwigger, 2025⁠).

CVE-2026-3055 in Citrix NetScaler is the one attackers actually used. Citrix describes it as a memory overread from insufficient input validation, exploitable only when the appliance is configured as a SAML IdP (Citrix CTX696300⁠). A malformed request to its /saml/login endpoint triggers an out-of-bounds read that returns leftover process memory to the attacker, base64-encoded in the NSC_TASS cookie, which can expose session material and enable session hijack (watchTowr, 2026⁠). It scores 9.8 NVD v3.1 (9.3 CNA v4.0), and CISA added it to the Known Exploited Vulnerabilities catalog on March 30, 2026, with active exploitation confirmed (NVD CVE-2026-3055⁠).

CVE-2025-55241 in Microsoft Entra is the clean OIDC counterpoint. A cross-tenant flaw let actor tokens minted in an attacker's tenant be accepted by the legacy Azure AD Graph API in any other tenant, with no pre-existing access required, scored 9.8 NVD v3.1 (10.0 Microsoft). Microsoft mitigated it server-side on July 17, 2025 before CVE assignment, with no customer action required, and reported no detected abuse (Microsoft MSRC, 2025⁠; Dirk-jan Mollema, 2025⁠).

Provider security track record

Weigh impact and disclosure quality over raw CVE counts. A vendor with more published CVEs and fast, candid disclosure is often safer than a quiet one. Two axes matter: how accurately the vendor scoped impact, and how quickly customers were protected.

Okta's 2023 support-system breach is the scoping case. Attackers used stolen credentials to reach Okta's support case-management system and HAR files containing session tokens. Okta revised its impact estimate from 134 customers to all support-system users about six weeks after initial disclosure (Okta Security, 2023⁠). Three customers, 1Password, Cloudflare, and BeyondTrust, independently detected the anomalous activity and reported it before Okta's own disclosure; Cloudflare says it contacted Okta about the breach before Okta notified Cloudflare, and that BeyondTrust first flagged it to Okta on October 2, 2023 (Cloudflare, 2023⁠; 1Password, 2023⁠). In the earlier 2022 Lapsus$ incident, Okta first put the maximum potential impact at 366 customers, and its final investigation concluded the threat actor had actually accessed 2 (Okta, 2022⁠; Okta, 2022⁠). In 2022, Auth0 disclosed that source-code repositories from October 2020 and earlier had likely been copied, with no platform compromise and no customer data accessed, after an external party notified the company (Auth0, 2022⁠). Microsoft Entra's CVE-2025-55241 sits at the other end: a maximum-severity flaw fixed server-side with no customer action and no exploitation. Readers can weigh these themselves.

Clerk is a short, positive example of disclosure process. CVE-2024-22206, an IDOR in auth() and getAuth(), was scored 9.8 (NVD v3.1) and 9.0 (CNA). Clerk found it during an internal code audit on January 9, 2024, contacted Cloudflare, Netlify, and Vercel the same day to coordinate network-layer mitigation, and shipped the patch in @clerk/nextjs 4.29.3 about three days later, before public disclosure (NVD CVE-2024-22206⁠). The no-confirmed-compromise statement attaches only to this CVE: the January 12, 2024 changelog says "while we are not aware of any exploit, we unfortunately cannot be sure without access to the server's logs" (Clerk Changelog, Jan 12 2024), and the February 2, 2024 post-mortem says "no customers have reported evidence of an exploit" (Clerk Changelog, Feb 2 2024). Clerk has disclosed later CVEs the same way, including CVE-2025-53548 in verifyWebhook() (7.5) and a 2026 trio: CVE-2026-41248 (createRouteMatcher bypass, 9.1 CNA), CVE-2026-42349⁠ (has() and auth.protect() bypass, 8.1 NVD v3.1; 7.6 CNA v4.0), and CVE-2026-34076⁠ (SSRF via the opt-in clerkFrontendApiProxy, 7.4 CNA). The no-compromise claim does not extend to those; CVE-2026-41248 carries only a scope statement that sessions are not compromised and no existing user can be impersonated, only the middleware-level gating decision is bypassed (NVD CVE-2026-41248⁠). None of Clerk's CVEs are on the CISA KEV catalog. Clerk publishes a formal vulnerability disclosure policy.

In Part 3, we will complete the risk assessment framework and provide the definitive decision guide, concluding with the pragmatic answer of supporting both protocols.

FAQ

What is the SSO tax? The SSO tax refers to the practice of vendors charging premium rates or requiring enterprise tiers to enable Single Sign-On, significantly increasing the total cost of ownership for buyers.

Why is TCO important when choosing a protocol? The protocol itself is free, but the infrastructure to support it is not. TCO includes provider licensing, integration effort, and security maintenance. Evaluating these ensures the chosen solution fits your long-term budget.

Are SAML XML parsing vulnerabilities common? Yes, improper XML signature validation and entity expansion in SAML implementations have historically led to severe bypass vulnerabilities, which is why relying on vetted providers is safer than custom implementations.

In this series

1. OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide
2. OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide - Part 2 (you are here)
3. OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide - Part 3
4. OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide - Part 4