The math lands at a specific moment. You are mapping out your unit economics, you open the auth provider's pricing page, and you realize the cost scales with the one number you most want to grow.
Per-user auth pricing was built for a particular kind of business: enterprise SaaS where each account represents a paying customer. Revenue and user count move together. The vendor takes a percentage of your growth, and the arrangement makes sense for everyone involved.
Most products today do not fit that description.
If you run a freemium product, a consumer app, or anything where a meaningful share of your users never pays, per-MAU billing charges you for accounts that generate no revenue. If you are growing fast, the cost curve bends upward faster than your revenue curve. Neither situation is what the pricing model was designed for.
Four alternative models exist. Each one charges for something else. Understanding what each charges instead is how you choose the right one for your product.
Why per-user pricing became the default
Auth providers built their pricing on a reasonable assumption: authentication correlates with value. More users means more revenue, and some fraction of that should flow back to the provider keeping those users logged in.
For the products that model was designed around, it holds. A B2B SaaS charging $500 per seat per year can absorb $0.02 per monthly active user without it registering on the income statement. The provider captures a sliver of the customer's growth. Nobody argues.
The assumption breaks the moment user count and revenue decouple. Consumer apps, tools with generous free tiers, and platforms that monetize a small percentage of their registered base all face the same structural problem: they pay for users who generate no revenue. At modest scale, that cost is manageable. At 100,000 MAU with a 4% conversion rate, a per-user auth bill starts to look like a meaningful percentage of actual revenue rather than a rounding error.
The four alternatives below become worth understanding in that context.
The four models that skip per-user billing
Self-hosted libraries
Self-hosted auth means running your authentication stack on your own infrastructure. You pay for compute, storage, and engineering time. There is no per-login meter.
Better Auth is an MIT-licensed, TypeScript-first library that runs inside your own codebase against your own database. Keycloak, SuperTokens OSS, and Logto OSS occupy similar territory. Each is open source, each gives you complete control over data and deployment, and none of them has a billing rate tied to user count.
The cost question shifts from 'how many MAU do you have' to 'what does it cost to run this reliably.' At 5,000 users, a small compute instance handles auth without strain and the monthly infrastructure cost is close to zero. Past 50,000 users, the calculus does not change because the software charges more. It changes because you are running something in production that needs monitoring, updates, and someone available when something breaks.
The honest counterweight on self-hosting is this: you trade a recurring vendor cost for a recurring ownership cost. That ownership cost does not appear as a line item anywhere. It shows up in engineering hours, in the Friday afternoon someone spends applying a security patch, and in the weight of carrying one more system.
Where it makes sense: products where engineering capacity is high, where data residency requirements make third-party auth difficult, or where user count is large enough that per-MAU pricing would be structurally painful.
Bundled auth
Some platforms include authentication as part of a broader product offering, with a large user allowance rather than no meter at all. Supabase Auth ships with any Supabase project. If you are already paying for Supabase to handle your database and file storage, auth comes along without a separate line item.
The cost model here is indirect, but it is not uncapped. Supabase includes 50,000 monthly active users on the free plan and 100,000 on paid plans, then charges $0.00325 per additional user. Below the ceiling, auth genuinely does not show up as its own line. Above it, you are back on a per-user meter, just a cheaper one than the dedicated providers charge.
The constraint is coupling. If Supabase is the right database layer for your product, bundled auth is a clean and efficient choice. If you would not otherwise use Supabase, adopting an entire platform specifically to get free auth is a different calculation with its own set of tradeoffs.
Where it makes sense: products already built on a platform that bundles auth, where the platform dependency is acceptable, switching cost is low, and your user count sits comfortably inside the included allowance.
High free ceiling managed auth
A third model sets the free tier high enough that most products never exceed it. WorkOS AuthKit provides basic authentication free to one million monthly active users, then $2,500 a month for each additional million.
For most products at most stages, one million MAU is not a near-term constraint. The ceiling is high enough to function as free auth for practical purposes across the majority of a typical product's lifecycle, with the understanding that enterprise features, SSO, and directory sync sit outside the free tier.
The distinction worth keeping clear: you are not escaping per-user pricing, you are staying inside a very large free band. Once you approach that ceiling or need features beyond basic authentication, the pricing structure changes and the model no longer behaves the same way.
Where it makes sense: products in early and mid-stage growth where basic auth covers the use case and the free ceiling is genuinely out of reach.
Revenue-metered auth
The fourth model inverts the logic. Instead of billing per account, it bills per transaction.
tiun sits here. Authentication flows, checkout, the customer database, and the self-serve portal all run on the free core tier. Charges fall on transactions, not on account registrations. A product with 100,000 registered users and 5,000 paying customers pays for the 5,000 transactions, not for the 100,000 accounts.
The fit condition for this model is specific: it works well when most of your users are also payers, or when transaction volume tracks reasonably with revenue. It fits badly when you carry a large free user base that rarely or never transacts. If your product has 200,000 registered users and generates 400 transactions per month, the revenue-metered model does not save you from a structural mismatch. It just prices a different metric that happens to be small.
Where it makes sense: products where users and payers largely overlap, and where auth costs tracking transaction activity rather than account volume matches how the business actually works.
Where per-user pricing is still the right answer
Per-user auth pricing is not wrong by default. It is wrong for specific product shapes.
If your users closely track your revenue, if your product is primarily B2B with high average revenue per account, and if you want a managed service that handles security updates, compliance certifications, and uptime without internal ownership, a per-user provider is a defensible choice. Cost scales with success, the vendor carries the operational weight, and total spend is predictable relative to revenue.
The case against it applies specifically to decoupled growth: when user count grows faster than revenue, or when a large share of users never generate revenue. In those two situations, the billing model works against you.
Choosing by model
Self-hosted: carry this if you have engineering capacity to own it, if data residency requirements rule out third-party providers, or if your user count is high enough that per-MAU pricing creates real pressure.
Bundled: carry this if you are already on a platform that includes auth, have no reason to separate the two, and stay inside the included user allowance.
High free ceiling: carry this while you are within the free band and basic auth covers your use case. Revisit as you approach the ceiling or as feature requirements grow.
Revenue-metered: carry this if your users and payers largely overlap and you want auth costs to track transaction activity rather than account registrations. Be honest about whether that overlap actually exists in your product.
Per-user managed: carry this if your ARPU is high, your user count is moderate, and you want a vendor to carry the operational weight without you building or managing anything.
The structural question underneath all of this is what you are actually paying for. Per-user pricing says you pay for accounts. The alternatives say you pay for compute, for a platform bundle, for staying inside a ceiling, or for transactions. None of those is inherently better. Each is better for a specific product shape.
The model you choose should match the way your product actually generates revenue. If it does not, the cost shows up eventually, either in the bill or in the ownership burden you did not account for.
Frequently asked questions
At what user count does per-user auth pricing become a real cost problem?
The number itself is less important than the ratio. Per-user auth pricing becomes a structural problem when your user count and your revenue decouple - specifically, when a large share of your users never pay. A freemium product with 100,000 MAU, a 5% paid conversion rate, and $10 per month pricing generates roughly $5,000 in monthly revenue. Per-user auth at typical rates runs $500 to $2,000 per month at that scale, which is 10 to 40 percent of actual revenue for a single infrastructure line item. That is the point where the billing model is working against you. For a B2B product where most users are paying customers, the same user count generates far more revenue and the auth cost remains negligible by comparison.
What is the difference between per-user and per-transaction auth pricing?
Per-user auth pricing charges based on the number of monthly active users in your product, regardless of whether those users generate revenue. Per-transaction auth pricing charges based on completed financial transactions — purchases, subscriptions, or billing events — rather than account registrations. The practical difference is significant for products with a large free user base: under per-user pricing, 100,000 registered users and 5,000 paying customers means paying for all 100,000 accounts. Under per-transaction pricing, you pay only for the 5,000 transactions tied to actual revenue. The tradeoff is that per-transaction pricing fits badly when your free user base rarely or never transacts, because the model assumes a reasonable overlap between users and payers.
Does switching to Supabase Auth eliminate per-user authentication costs?
Supabase Auth does not bill separately based on user count. Authentication ships as part of the Supabase platform, so your auth costs are bundled into your overall Supabase spend rather than metered per monthly active user. This means adding users does not increase your auth bill in isolation. The cost model is indirect: you pay for the platform (compute, database, storage), and auth is included. The constraint is that this only makes sense if Supabase is already the right infrastructure choice for your product. Adopting Supabase specifically to avoid per-user auth pricing, when you would not otherwise use it, trades one cost for a platform dependency that carries its own tradeoffs.
Can you use WorkOS AuthKit free at scale, or does the cost kick in before you grow?
WorkOS AuthKit provides basic authentication free up to one million monthly active users. For most products at most growth stages, that ceiling is not a near-term constraint — one million MAU is well beyond where the majority of SaaS products operate. Basic auth, social login, and standard session management are included within the free tier. The costs that do apply are for features outside basic authentication: enterprise SSO, directory sync (SCIM), and advanced organization management. If your product needs those features, you are no longer on the free tier regardless of user count. The ceiling is genuinely high for core authentication, but it is not a permanent escape from per-user pricing — it is a very large free band that eventually has an edge. Verify current pricing on the WorkOS site before committing, as free tier terms have changed before.