Daniel Kim

Posted on Aug 20

Clerk Wrote the 'Real Cost of Enterprise SSO' Benchmark Everyone Cites. Clerk Also Wins It.

#authentication #saas #api #security

Your startup just closed its first six-figure enterprise deal. The champion on the buyer's side is thrilled. Then procurement sends over a security questionnaire, and line one says: "Must support SSO via SAML or OIDC, with SCIM provisioning, before contract signature."

You now have 30 days to bolt enterprise identity onto a product that was built for self-serve signups. This is one of the most common forcing functions in B2B software, and in 2026 there are more ways to solve it than ever — Clerk, WorkOS, Auth0 (owned by Okta), and Supabase Auth all now sell some version of "enterprise SSO in an afternoon." What almost nobody writes about is that these four products don't just differ in features — they meter the exact same capability (one SAML connection, one directory sync) using four structurally different pricing models, and the gap between them compounds fast once you're not selling to one enterprise customer but ten.

That's the actual decision point. Not "which auth provider is best," which is a question with no stable answer, but "which pricing architecture matches how my enterprise pipeline is going to grow" — a question you can actually reason about with real numbers.

Why this is a live decision right now

Three of these four vendors changed their enterprise pricing in 2026. Clerk ran a full B2B pricing overhaul in February. WorkOS shipped Directory Sync (its SCIM product) to general availability and kept iterating its per-connection ladder. Auth0, under Okta, has been pushing customers who outgrow its free tier into what several third-party analyses now call a "B2B premium" — a multiplier on the base price rather than a flat per-connection fee. Supabase, meanwhile, folded SAML SSO into its existing plan structure rather than shipping it as a separate product, which sounds simpler until you look at how it's actually metered.

None of this is settled. If you're picking an auth vendor this quarter, you're picking during an active repricing cycle across the entire category, which means the marketing pages you're reading right now may already be stale by the time you're negotiating a contract at scale.

What each platform actually sells

Clerk is a vertically integrated auth product: prebuilt sign-in/sign-up UI components, session management, organizations/multi-tenancy, and — as of its 2026 overhaul — enterprise SSO and SCIM bundled into the same connection object. You drop in their React/Next.js/etc. components and get a working enterprise login flow with comparatively little custom UI work.

WorkOS is explicitly API-first and headless. Its free product, AuthKit, covers email/password, social login, MFA, and user management up to a very large user count. Enterprise SSO and Directory Sync (its SCIM offering) are separate, paid, metered-per-connection products layered on top. You write your own UI; WorkOS gives you the protocol plumbing.

Auth0, now part of Okta, is the incumbent enterprise identity platform — the one most likely to already be evaluated by a buyer's security team, because it's been through the most compliance audits and supports the longest tail of identity providers and edge-case SAML/OIDC configurations. It's also the most opaque on pricing once you cross a modest user threshold.

Supabase Auth is GoTrue, Supabase's open-source auth server, sold as one feature of a broader backend-as-a-service platform that also includes Postgres, storage, and edge functions. SAML SSO is a checkbox you enable on an existing Supabase project rather than a separate product you integrate.

How they're built, and why that shapes the cost

The architectural split roughly tracks the pricing split.

Clerk and Supabase are both "your app talks to our hosted service, we hand you sessions and UI primitives" — the difference being that Clerk is a single-purpose auth vendor while Supabase auth is one module of a full backend platform. That coupling is exactly why Supabase's SSO pricing looks different from everyone else's: it's not priced as "here's a new product," it's priced as "here's a new usage dimension on your existing project" — a per-MAU meter for SSO-authenticated users, layered on top of your regular Postgres/API/storage bill.

WorkOS is closer to a headless identity broker: it normalizes SAML, OIDC, and SCIM into one clean API and lets you keep full control of your UI and session logic. That's the reason engineering-led teams gravitate to it — but "headless" also means every enterprise connection is priced as a discrete, metered object, because WorkOS isn't selling you a UI or a user database, just the identity federation layer itself.

Auth0/Okta is the oldest and most feature-complete of the four, built up over more than a decade of enterprise identity edge cases — legacy SAML quirks, unusual IdP behaviors, unusual claim mappings. That maturity is real, and it's also why its pricing doesn't fit neatly into a per-connection ladder: Auth0 sells tiers (Essentials, Professional, Enterprise) that bundle a basket of enterprise features together, so what you're really paying for is tier access, not a specific connection count.

What changed in 2026, concretely

Clerk, following its February 2026 B2B pricing overhaul, now includes on its free tier: 25,000 MAU, one enterprise connection, self-service SSO, and SCIM. SCIM (branded Directory Sync equivalent) reached general availability on April 16, 2026, and group-to-role mapping plus custom attribute mapping followed on May 21, 2026. On the paid Pro tier ($25/mo base), additional connections are billed at $75/mo for connections 2–15, $60/mo for 16–100, $30/mo for 101–500, and $15/mo above that — with SCIM bundled free onto every connection at every tier, not charged separately.
WorkOS kept AuthKit (its base auth product: email/password, social login, MFA, user management) free up to 1,000,000 MAU. But SSO is priced on its own ladder: $125/mo per connection for the first 15, stepping down to $100 (16–30), $80 (31–50), $65 (51–100), and $50 (101–200), with custom pricing above that. Directory Sync (SCIM) runs on the same ladder as a separate line item — so a single enterprise customer that needs both SSO and provisioning is billed twice at the entry tier: $125 + $125 = $250/mo for one customer.
Auth0 doesn't publish a per-connection price at all in its public materials. Its free plan reportedly includes SSO and SCIM for a small number of connections under a 25,000 MAU ceiling, but once you need a paid B2B tier, you're paying a broad multiplier over the equivalent consumer-auth plan rather than a line-item connection fee — and above roughly 20,000 MAU, Auth0 pricing goes fully custom, meaning you're on the phone with sales to get a number at all.
Supabase offers SAML 2.0 SSO starting on its Pro plan ($25/mo base) and above, but meters SSO-authenticated users separately from regular MAU: $0.015 per SSO MAU above your plan's included quota. Its docs also list an Advanced MFA add-on (roughly $75/mo per project) as a related but distinct line item. Supabase doesn't publish enterprise-scale pricing at all — like Auth0, it goes to negotiated contracts once you're a serious enterprise seller.

Modeling the actual cost, not the sticker price

The number that matters isn't "what does one connection cost" — it's "what does my cost curve look like as my enterprise logo count grows," because that's the variable most B2B startups actually control least well (enterprise sales cycles are lumpy, and you'll sign five customers in a quarter you didn't plan for, or none).

Run Clerk's own published ladder out to 100 total connections: connection 1 is free, connections 2–15 (14 of them) cost $75/mo each ($1,050/mo), and connections 16–100 (85 of them) cost $60/mo each ($5,100/mo). That's $6,150/mo, plus the $25/mo Pro base — roughly $6,175/mo for 100 enterprise connections, SCIM included, based on arithmetic against Clerk's public pricing table.

WorkOS, at the same 100-connection mark, is reported to run roughly $6,500/mo for SSO alone, and roughly $13,000/mo once you add Directory Sync/SCIM on every connection — because SCIM is billed as a second, separate metered product rather than bundled. At that scale WorkOS is somewhere between roughly the same as Clerk (SSO only) and more than double Clerk's cost (SSO + provisioning), depending on how many of your enterprise customers actually need directory sync versus just SSO.

Third-party procurement data adds useful ground truth here: Vendr's 2026 buyer-side benchmarks put the average WorkOS contract at roughly $21,292/year, with Spendhound's enterprise-tier average closer to $86,580/year — numbers that reflect real negotiated contracts rather than list-price ladders, and that tend to run higher than the sticker math because enterprise buyers rarely stay at exactly the published tier boundaries.

Auth0 and Supabase are harder to model this way precisely because they don't expose a clean per-connection or per-customer unit past a certain scale — which is itself informative. If you can't build a spreadsheet from public pricing, that's not a neutral fact, it's a signal that the vendor wants your first real conversation about enterprise pricing to happen inside a sales call, where anchoring and discount tactics work in their favor rather than yours.

Where these benchmark numbers actually come from

Here's the part worth sitting with before you trust any comparison, including this one. Searching for "Clerk enterprise SSO pricing 2026" surfaces almost entirely — page after page — content published directly on clerk.com/articles: titles like "Auth Platforms With SSO and SCIM in the Base Tier," "The real cost of enterprise SSO: per-connection vs per-MAU pricing," and "OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide." These are competitive content-marketing pieces, written by Clerk, comparing Clerk favorably to WorkOS and Auth0 on the exact metric — per-connection cost at scale — where Clerk's newer, bundled-SCIM pricing structure wins.

That doesn't make the underlying numbers false. Clerk's pricing ladder is public and independently verifiable; WorkOS's is too. But it does mean that if your primary source for "here's what enterprise SSO really costs across vendors" is a vendor's own comparison page, you're reading a brief written by one side's lawyer, not a court transcript.

The most useful independent check found during this research is a third-party dev.to piece by a smaller identity-infrastructure vendor, comparing SAML costs across Auth0, WorkOS, and Clerk, which — while also not a neutral party, since its author sells a competing product — used its own modeling and arrived at directionally similar conclusions with different absolute numbers: at 10,000 MAU with 3 SAML connections issued over a year, it puts WorkOS at roughly $9,000 against Clerk's roughly $2,100, with Auth0 unquotable because it's custom-priced. At 50,000 MAU with 10 connections, the same analysis puts WorkOS at roughly $30,000 against Clerk's roughly $8,400. Two differently motivated sources landing on "WorkOS is meaningfully more expensive per connection at scale, Auth0 is opaque" is a stronger signal than either piece alone — but it's still not the same as an auditor's numbers, and you should run your own math against your actual expected connection count before believing any of it, including this article.

What each vendor's pricing page doesn't say

Clerk's "SCIM is free" claim is true only in the narrow sense that SCIM isn't billed as a separate line item — you're still paying the same per-connection fee whether that connection uses SSO alone or SSO plus provisioning. The marketing framing ("free SCIM") obscures that you're not getting provisioning at zero incremental cost so much as you're not being charged twice for one customer relationship, which is a real and meaningful difference from WorkOS but not literally "free."

WorkOS's "free to 1,000,000 MAU" headline describes AuthKit — email/password, social login, basic MFA, user management. It says nothing about enterprise SSO or SCIM, which is the feature that actually triggers when a security questionnaire lands on your desk. A startup that reads the "1M MAU free" number and assumes enterprise auth is covered will be surprised by the first $125/mo connection invoice.

Auth0's custom pricing above ~20,000 MAU means the number you'd use to compare it against the other three in a spreadsheet simply doesn't exist publicly. That's not a neutral omission — opaque, negotiated pricing structurally favors the seller, who knows your alternatives and your urgency, over the buyer, who's often evaluating this decision under a signed-deal deadline and limited leverage.

Supabase's SSO-MAU metering is easy to miss if you're already budgeting Supabase as "the Postgres bill" — it's a genuinely separate usage dimension from your regular MAU count and your database compute, and it's not prominently modeled in most Supabase cost calculators floating around online, which tend to focus on database size and bandwidth.

None of the four vendors' marketing pages will proactively tell you "the number you're looking at doesn't include what you actually need." You have to build the model yourself.

Comparison table

Dimension	Clerk	WorkOS	Auth0 (Okta)	Supabase Auth
Base free tier	25,000 MAU, includes core auth	AuthKit free to 1,000,000 MAU (no enterprise features)	Free tier available, low MAU ceiling	No free SSO tier; requires Pro plan ($25/mo)
First enterprise (SSO) connection	Free (1 included)	Not included free — priced from connection 1	Reportedly free at low tier, unclear at scale	Bundled into plan access, metered per SSO-MAU
SSO pricing unit	Per connection, tiered ladder	Per connection, tiered ladder	Tier/plan premium, not per-connection	Per SSO-authenticated MAU ($0.015 above quota)
Entry-tier SSO cost	$75/mo (2nd–15th connection)	$125/mo (1st–15th connection)	~$150/mo B2B "Essentials" tier	Included in $25/mo Pro base + usage
SCIM/provisioning cost	Bundled free with every connection	Separate metered product, same ladder as SSO	Bundled at low tier, unclear at scale	Not clearly self-serve; enterprise negotiation
Est. cost at 100 connections	~$6,150–6,175/mo (SSO + SCIM)	~$6,500/mo SSO-only; ~$13,000/mo w/ SCIM	Custom quote required	Not directly comparable (per-MAU, not per-connection)
Architecture	Vertically integrated, prebuilt UI	Headless, API-first, bring-your-own-UI	Mature standalone IAM platform	Open-source GoTrue, bundled into backend platform
Vendor lock-in shape	Higher — UI + session model tied to Clerk	Lower — swappable identity layer only	Medium — gravity toward Okta ecosystem	Higher if already dependent on Supabase backend
Publicly modelable at scale	Yes	Yes, up to 200 connections	No (opaque above ~20k MAU)	Partially (per-unit rate published, totals aren't)
Best-fit team	Product-led SaaS moving upmarket fast	Engineering-led teams wanting control + own UI	Orgs needing deepest IdP coverage / Okta shops	Teams already all-in on Supabase for backend

Security, maintainability, and lock-in

On raw identity-provider compatibility and enterprise compliance maturity, Auth0 still has the longest track record — it's been the default "safe choice" for enterprise buyers' security teams for the better part of a decade, and that history is worth real money if your sales cycles keep stalling on security review. Clerk and WorkOS are both newer but have shipped SAML/OIDC/SCIM support that covers the vast majority of real-world IdP configurations (Entra ID, Okta Workforce, Google Workspace) that a typical B2B startup will actually encounter; you're more likely to hit an edge case with a long-tail legacy IdP on Auth0's list than on theirs, but you're also less likely to need that edge case than you think.

Lock-in runs in the opposite direction from what the marketing implies. Clerk's biggest strength — prebuilt UI components and deep session integration — is also what makes it the hardest of the four to rip out later, because you didn't just buy an identity API, you built your login and account-management UI on top of Clerk's abstractions. WorkOS is deliberately the opposite: because it's headless, swapping it for a competitor later mostly means changing API calls behind a UI you already own. Supabase's auth is technically open source (you can self-host GoTrue), which sounds like an escape hatch, but in practice almost nobody self-hosts it separately from the rest of their Supabase project, so the real-world lock-in looks a lot more like Clerk's than the "open source" label suggests.

Developer experience and the migration question nobody prices in

The four also diverge sharply on time-to-first-working-login, which is a real cost even though none of the vendors put a dollar figure on it. Clerk's prebuilt components mean a working enterprise sign-in page can genuinely ship in an afternoon, because you're wiring up a component rather than hand-building a SAML redirect flow and session cookie logic. WorkOS gets you the same protocol correctness — its SDKs handle the SAML assertion parsing and OIDC token exchange — but you still own the login page, the loading states, the error handling for a misconfigured IdP, and the session store. That's more work up front and more flexibility later, and which one of those you want depends entirely on whether your team already has an opinionated design system it doesn't want a vendor overriding.

Auth0's SDKs are the most battle-tested against unusual identity provider behavior, which mostly shows up as an invisible cost: fewer late-night pages from a customer's IT department because their specific ADFS configuration doesn't match the SAML spec exactly. That reliability under edge cases is real, but it's also the hardest of the four benefits to verify before you've signed a contract and started onboarding actual enterprise customers, because you don't know which edge cases you'll hit until you hit them.

Latency and data residency rarely show up in these comparisons at all, and they should. WorkOS and Auth0 both operate in multiple regions and can meet data-residency requirements that show up in EU or regulated-industry security questionnaires; Clerk's regional footprint has historically been narrower, though it's expanded this alongside its 2026 pricing changes. Supabase inherits whatever region your underlying Postgres project lives in, which is convenient if you already picked a compliant region for your database and a problem if you didn't think about auth residency separately when you provisioned it.

On migration cost specifically — the question worth asking before you sign with any of the four — moving between them later is never free, but the size of the bill differs by architecture in a way that maps back to the lock-in discussion above. Leaving WorkOS mostly means re-pointing API calls behind a UI you already built, which is a few weeks of engineering work for a mid-sized user base. Leaving Clerk means rebuilding the login, sign-up, and account-management UI you didn't build yourself the first time, on top of migrating session state — a materially bigger project, and one teams tend to underestimate until they're mid-migration. Leaving Supabase Auth means migrating both your identity data and, likely, deciding what to do about the rest of your Supabase-hosted backend at the same time, which is rarely a decision made in isolation.

Which reader should pick which option

You're pre-enterprise, closing your first SSO-gated deal, and need this working in weeks, not a quarter: Clerk's free first connection and bundled SCIM make the initial deal essentially free to unlock, and the UI components save real engineering time you don't have. The tradeoff you're accepting is UI lock-in you'll feel later if you ever want to fully own your auth surface.

You're an engineering-led team that already owns its UI, expects to sign enterprise customers steadily rather than in one lump, and wants to negotiate volume pricing later: WorkOS's headless model keeps you in control, and its ladder is genuinely competitive if most of your customers need SSO but not SCIM (skip the doubled cost). Budget carefully once you cross roughly 20–30 simultaneous enterprise connections, where the gap versus Clerk widens.

You're selling into large enterprises with mature security teams, possibly already inside the Okta ecosystem, and identity-provider edge cases are a real risk to your sales cycle, not a hypothetical: Auth0 is still the safest default on compatibility and compliance pedigree, but go in expecting an opaque, negotiated number rather than a spreadsheet you can build yourself — get multiple quotes and don't accept the first one.

You're already running your backend on Supabase and don't want a second vendor relationship for auth: Supabase Auth's SSO support is genuinely convenient if you're already there, but model the per-SSO-MAU metering explicitly against your expected enterprise user counts before you assume it's cheaper than a dedicated product — it's a different cost curve, not automatically a lower one.

The independent read

Every vendor in this category has converged on the same underlying move: charge close to nothing for consumer-style auth to win developer adoption, then meter enterprise features — the ones that show up the moment a real B2B deal requires them — as a distinct, higher-margin product line. That's not a criticism unique to any one of these four; it's the economically rational structure of the whole category, because enterprise buyers have budget and self-serve users don't. The mistake is treating any single vendor's free tier as evidence that enterprise auth is cheap. It isn't, anywhere, and the "real cost of SSO" comparisons circulating right now are disproportionately funded and published by the vendor that wins them. Build your own model from the public tier tables, run it against your actual expected connection count over the next 12 months — not today's count — and treat any number above roughly 20,000 MAU or 20 connections as a starting point for a negotiation, not a quote.

Discussion: if you've actually priced out enterprise SSO for a real deal — not a hypothetical — which model burned you more: getting nickel-and-dimed per connection as you scaled, or hitting an opaque "contact sales" wall right when you had the least negotiating leverage? And did switching providers later (if you did) actually save what the spreadsheet promised once migration effort was factored in?

Sources:

DEV Community