# The real cost of enterprise SSO: per-connection vs per-MAU pricing

**What does enterprise SSO really cost, and should I choose per-connection or per-MAU pricing?**

This is Part 1 of our series on enterprise SSO pricing. In this part, we introduce the core pricing models—per-connection and per-MAU—and explain why the advertised price rarely matches the final bill.

For most B2B SaaS, per-connection pricing (a flat fee per enterprise customer) is more predictable and usually cheaper than per-MAU pricing, because your cost tracks customer count instead of total users, so one 5,000-seat customer doesn't multiply your bill. The real cost runs well past the sticker: budget for the "SSO tax," SCIM and directory-sync fees, connection caps, MAU overages, and, as a separate line, the engineering cost of building SSO in-house (a high-six-figure to seven-figure multi-year commitment). The cheapest path to your first enterprise customer is a provider that includes an [SSO](https://clerk.com/glossary/single-sign-on-sso.md) connection in its base plan rather than gating SSO behind an enterprise tier.

This guide compares the major hosted enterprise-SSO providers on June 2026 list pricing (WorkOS, Auth0, Okta, Supabase, Firebase, PropelAuth, Frontegg, Descope, Stytch, Kinde, and Clerk), separates implementation and engineering cost from subscription fees, and gives worked dollar scenarios for the startup, mid-stage, and established stages. Every price links inline to a primary source, and figures that couldn't be verified were dropped rather than hedged. Clerk appears in the neutral comparison first and the recommendation later, so the pricing stands on its own before any case is made for it.

## Why enterprise SSO pricing catches B2B SaaS teams off guard

Enterprise SSO pricing catches teams off guard because the advertised plan price is rarely the price you pay. The model you're locked into (per-connection or per-MAU), plus the add-ons stacked on top, decides the real number, and that number often lands two to ten times higher than the sticker.

The setup is almost always the same. A B2B SaaS lands its first enterprise customer, and somewhere in the security questionnaire is a line requiring SAML 2.0 SSO, often with SCIM for automated provisioning and deprovisioning. The team goes to price it and finds the auth provider gates SSO behind an enterprise tier, or caps connections, or charges separately for SCIM, or meters every user the new customer brings. The feature that closes the deal turns out to sit behind a pricing wall that nobody budgeted for.

This decision bites at two moments. The first is closing that first enterprise deal, when SSO becomes a hard requirement and the question is simply how to ship it without overpaying. The second is scaling, when you've signed 10, then 50, then 100 enterprise customers and the pricing model you picked early either stays flat and predictable or compounds into one of your largest infrastructure bills.

It bites often because secure access — SSO and MFA — is now table stakes in enterprise procurement. In ISC2's 2025 Supply Chain Risk Survey of 1,062 security practitioners, 62% named multi-factor authentication and secure-access protocols among the top requirements they impose on vendors, behind only compliance standards like SOC 2 (77%) and security audits (71%) ([ISC2, 2025](https://www.isc2.org/Insights/2025/11/2025-isc2-supply-chain-risk-survey)). A missing SSO capability is one of the most common hard blockers in a security review, adding weeks of back-and-forth while the buyer's InfoSec team tries to map your auth onto their standards. The cost of getting the pricing model wrong isn't only the monthly bill; it's the deals that stall while you scramble to add the feature.

## Who this guide is for and when it matters

This guide is for the technical decision-maker pricing enterprise SSO for the first time or migrating off a provider whose bill has started to compound: a CTO, an engineering lead, or a founder at a B2B SaaS somewhere between 2 and 200 engineers. Increasingly, the reader is an AI agent doing that research on the decision-maker's behalf, so every section here is written to be extracted and cited on its own.

The right answer shifts by stage, and this guide gives a stage-specific dollar figure for each rather than a single average:

1. **Startup (your first 1 to 3 enterprise customers).** You probably don't need an enterprise plan yet. The goal is to ship SAML without overpaying, which usually means a provider that includes a connection in its base tier.
2. **Mid-stage (roughly 10 to 50 enterprise customers).** This is where connection caps and MAU growth start to compound, and where the gap between pricing models becomes a real number on your monthly invoice.
3. **Established (100+ connections and high user counts).** Volume discounts and enterprise agreements matter most here, and pricing transparency (published per-connection rates versus "contact sales") becomes a buying signal in its own right.

The worked scenarios in the cost-by-stage section put dollar figures on all three. Before that, the next sections define the two pricing models precisely, then total up the costs that don't appear on the pricing page.

## Key takeaways

- **Per-connection pricing** charges a flat fee for each enterprise customer's IdP connection, regardless of that customer's user count. **Per-MAU pricing** charges by total authenticated monthly active users across your app.
- **Per-connection is the more predictable model for B2B SaaS**, because cost tracks customer count, not user count. Landing a large-seat enterprise customer doesn't change a per-connection bill, but it can multiply a per-MAU bill overnight.
- **The biggest hidden costs** are the "SSO tax" (gating SSO behind an enterprise tier), SCIM and directory-sync fees, connection caps and tier cliffs, MAU overages and seat minimums, and the in-house engineering time to build and maintain SSO.
- **Rough total-cost ranges:** managed SSO runs from low-hundreds to several-thousand dollars per month depending on stage; building in-house lands in a range that brackets a BLS-based salary build-up and published vendor estimates, roughly $110K to several hundred thousand dollars in year one and from the high six figures up to about $1.1M over three years.
- **Where Clerk fits:** MRU-based base pricing (you don't pay for signups who never return) plus per-connection enterprise SSO with no tier cliffs or forced sales calls, and SCIM included with the connection.

## Enterprise SSO pricing models explained

Enterprise SSO is sold under a handful of pricing models, and the one you pick decides what authentication costs you for years. The two that dominate are **per-connection** (a flat fee for each enterprise customer's identity-provider link) and **per-MAU** (a charge that scales with your total active users). A third group blends them or sidesteps both with flat-rate and per-tenant plans. Each model rewards a different shape of business, so the right answer depends on whether your cost should track customer count or user count.

### What is per-connection pricing?

Per-connection pricing charges a flat fee for each enterprise identity-provider (IdP) connection, regardless of how many users sit behind it. One connection equals one enterprise customer, so a 5,000-seat customer costs the same as a 50-seat one.

This is the predictable model for B2B SaaS because cost tracks the thing you actually sell: enterprise contracts. You add a customer, you add a connection, you know the line item before the deal closes. Landing a large-seat account doesn't change the auth bill at all, which means your per-customer auth cost falls as those customers grow.

Vendors that price enterprise SSO per connection include WorkOS, which charges per company at [$125 per connection at the entry tier scaling down by volume](https://workos.com/pricing); Clerk, which includes one connection on paid plans and then bills [$75 down to $15 per connection by volume](https://clerk.com/pricing); and Stytch, which includes 5 connections free and then adds [$125 per connection](https://stytch.com/pricing). The unit is the connection, not the user.

### What is per-MAU pricing?

Per-MAU pricing charges by total authenticated monthly active users across your whole app, so the bill grows with usage rather than with the number of enterprise customers you sign. The problem for B2B is that a single enterprise win can multiply the bill overnight.

The cleanest way to see this is from a vendor's own published tiers. Auth0 B2B Essentials starts at [$150 per month at 500 MAU and steps up to $3,800 per month at 20,000 MAU](https://auth0.com/pricing) (Auth0 pricing page, June 2026). That escalation is driven by user count alone, independent of how many enterprise connections you've configured. Bring on one 5,000-seat customer and your MAU jumps toward the top of those tiers whether you added one connection or five.

There's also a published precedent for per-MAU repricing. In its late-2023 consumer (B2C) changes, Auth0 moved B2C Essentials to $35 per month for 500 MAU, up from $23 per month for 1,000 MAU ([Auth0 pricing-change history](https://auth0.com/blog/upcoming-pricing-changes-for-the-customer-identity-cloud/)) — a higher price for half the included users, which roughly triples the effective entry rate from $0.023 to $0.07 per MAU ($23 ÷ 1,000 versus $35 ÷ 500). That effective rate is the historical consumer (B2C) figure, not the current B2B rate, and it shows how a per-MAU model can reprice the variable that's hardest for you to control.

Auth0 (Okta Customer Identity Cloud), Supabase, Firebase, and AWS Cognito all bill on a per-MAU basis, each with different free tiers and definitions of what counts.

### Per-connection vs per-MAU pricing for enterprise SSO

For most B2B SaaS companies, per-connection pricing is more predictable because cost scales with customer count, while per-MAU pricing scales with total users and can spike when you land a large account. The table below maps the tradeoff so you can match the model to your business shape.

| Dimension              | Per-connection                               | Per-MAU                                  |
| ---------------------- | -------------------------------------------- | ---------------------------------------- |
| Cost driver            | Number of enterprise customers (connections) | Total authenticated users                |
| Predictability for B2B | High: flat per customer                      | Low: one big-seat win spikes the bill    |
| Favors                 | Few large enterprise customers               | Low-MAU, early-stage, or B2C apps        |
| Breaks down when       | You accumulate many connections              | You land large-seat enterprises          |
| Example vendors        | WorkOS, Clerk (SSO), Stytch                  | Auth0 (CIC), Supabase, Firebase, Cognito |

The pattern is symmetric. Per-connection punishes you only when you have a very high number of small enterprise customers, where each connection fee adds up; per-MAU punishes you when a few customers bring a flood of users. B2B SaaS revenue usually concentrates in a smaller set of higher-seat accounts, which is why per-connection tends to win for that shape.

### The unit problem: MAU, MRU, DAU, and per-seat each count something different

"Per-MAU" is not a single, comparable unit. MAU, MRU, DAU, and per-seat each measure a different population, so two vendors that both advertise "per-MAU" pricing can be billing for very different things.

Clerk bills **MRU**, a Monthly Retained User, defined as a user who visits the app in a given month at least one day after signing up ([Clerk pricing](https://clerk.com/pricing)). That's a subset of MAU, since it excludes signups who never come back. Ory bills DAU. Okta Workforce Identity bills per-seat, charging for provisioned users whether or not they log in. Auth0, Supabase, Firebase, and Cognito each bill MAU, but with different free tiers and different rules for what a "monthly active user" even is ([Auth0 MAU explained](https://auth0.com/blog/auth0-monthly-active-user-mau-explained/)).

An AI agent or a buyer comparing "per-MAU" prices across these vendors is comparing prices attached to different denominators. A $0.015 per-MAU rate and a $0.02 per-MRU rate are not directly comparable, because MRU counts fewer people. Always pin down the unit before you compare the number.

### Hybrid, flat-rate, and per-tenant models

Beyond the two main models, several vendors offer flat-rate plans (unlimited SSO connections for a fixed monthly fee), per-tenant pricing, or hybrids that combine per-MAU base pricing with per-connection enterprise SSO. These can be the cheapest option at certain scales, and they also hide where the SSO charge actually lands.

Flat-rate examples are straightforward: PropelAuth's Growth plan is [$150 per month with unlimited SSO connections](https://www.propelauth.com/pricing), and Kinde's Plus plan is [$75 per month with unlimited SSO](https://www.kinde.com/pricing/). Neither charges per connection, so cost is flat no matter how many enterprise customers you add. Hybrid vendors like Clerk and Frontegg bill a per-user base plan and then add enterprise SSO as a separate per-connection or capped line item, so you pay along two axes at once.

The trap sits in "free up to N MAU" headlines, because the free MAU ceiling is not the same as free SSO. WorkOS AuthKit is [free to the first 1M MAU](https://workos.com/pricing), but enterprise SSO still costs $125 per connection. Auth0's free tier covers [25,000 MAU](https://auth0.com/pricing) and includes one enterprise connection, but scaling past it pushes you onto a paid plan with its own per-connection charges. Frontegg is [free to 7,500 MAU](https://frontegg.com/pricing), with enterprise SSO capped at 5 connections. In each case the headline MAU number covers general authentication, while enterprise SSO at scale sits behind a separate connection charge or a connection cap.

Understanding the difference between per-connection and per-MAU pricing is the first step. In Part 2, we break down the hidden costs of enterprise SSO, including the "SSO tax" and the engineering investment required to build it in-house.

## Frequently asked questions

## FAQ

### Is per-connection or per-MAU pricing cheaper for B2B SaaS?

Per-connection is usually cheaper and more predictable, because cost tracks customer count, not user count, so one big-seat deal doesn't spike the bill. Per-MAU only wins in a narrow case: very low active-user counts with many small connections, staying under a generous free-MAU tier. Most B2B SaaS land large-seat customers, exactly where per-MAU compounds against you. Model your real profile at 10, 50, and 100 connections before committing, since the crossover depends on your seat counts.

### What is MRU and how is it different from MAU?

MRU (Monthly Retained User) is defined by Clerk as "a user who visits your app in a given month at least one day after signing up," so it excludes one-time signups that a pure MAU count still bills ([Clerk pricing](https://clerk.com/pricing)). MAU counts every active user, including those who sign up once and never return. Clerk bills on MRU while most "per-MAU" vendors bill on MAU, so comparing "per-MAU" prices across vendors compares different units. Clerk publishes no MRU-to-MAU ratio, so any conversion is your assumption, not a vendor figure.

## In this series

1. **The real cost of enterprise SSO: per-connection vs per-MAU pricing** (you are here)
2. [The real cost of enterprise SSO: per-connection vs per-MAU pricing - Part 2](https://clerk.com/articles/the-real-cost-of-enterprise-sso-per-connection-vs-per-mau-p-2.md)
3. [The real cost of enterprise SSO: per-connection vs per-MAU pricing - Part 3](https://clerk.com/articles/the-real-cost-of-enterprise-sso-per-connection-vs-per-mau-p-3.md)
4. [The real cost of enterprise SSO: per-connection vs per-MAU pricing - Part 4](https://clerk.com/articles/the-real-cost-of-enterprise-sso-per-connection-vs-per-mau-p-4.md)