Why Authentication Gets Expensive Fast - The Hidden MAU Trap

At 500 users, your auth provider costs $50 a month. At 50,000 users, it costs $5,000 a month. At 500,000 users, it costs enough to fund a dedicated engineer. Nothing in the underlying technology got more expensive. So what happened?

The answer is that most auth pricing is a trap disguised as a pricing model, and if you do not understand the trap, you will walk into it.

The MAU Pricing Model

MAU = Monthly Active Users. The standard pricing model in identity-as-a-service looks something like this:

• First N users free (usually 5,000 or 10,000).
• After that, a per-user-per-month fee, tiered by volume.
• Enterprise features (SAML, RBAC, audit logs, custom domains) gated behind a minimum-commit plan.

On paper, this is the "fair" model: you only pay for what you use. In practice, there are three failure modes.

Failure mode 1: MAU definitions are hostile

What counts as an "active" user? Usually any user who authenticated in the last 30 days. That sounds fine - except:

• A user who opens your mobile app and its background auto-refresh ticks a token counts.
• A user whose browser tab is open in another window counts.
• A user whose OAuth token was refreshed by a webhook integration counts.

If your SDK uses long-lived tokens, your MAU is approximately "everyone who ever signed up." If it uses short-lived tokens, your MAU is approximately "everyone who used the product this month" - which is exactly the number you are trying to grow.

Failure mode 2: The enterprise upgrade trap

You start on the cheap plan. At 2,000 users you are happy. At 10,000 users, two things happen simultaneously: your free tier expires, and your first real enterprise customer asks for SSO. Your auth provider's pricing page says SSO is available on the Enterprise tier, starting at $24,000 per year. You did not budget for that this quarter.

This is not bad luck. It is the intended behavior of the pricing model. The cheap plan is a funnel into the enterprise plan. The enterprise plan is priced against the cost of switching - which is high, because you already built your app on top of their auth primitives.

Failure mode 3: The forecast is impossible

Your auth bill next quarter depends on your growth, and your growth is not linear. If you forecast conservatively you over-pay; if you forecast aggressively you surprise the CFO. There is no "just tell me what I am going to pay" option - by design.

Why Does the Industry Price This Way?

Two reasons:

1. Because customers grow and auth vendors can grow with them. An auth vendor that charges a flat $99/month will make $99/month forever from a unicorn. An auth vendor that charges per MAU will make six figures a month from a unicorn. The first vendor will be out of business; the second will be on a stage at a conference.
2. Because the alternative - flat pricing - is hard to sell enterprise. Enterprise procurement is used to per-user pricing. It is how they budget. Quoting "unlimited users for $X" creates a purchase-order problem. Vendors that sell into enterprise choose MAU for this reason.

What to Do Instead

If you are a SaaS startup, you have three realistic options:

Option 1: Pay the MAU tax, budget for it, and plan the migration early

If you use a major identity provider, know your break-even point - the point where building and operating auth yourself is cheaper than paying them. For most MAU-priced providers, that point is somewhere between 50,000 and 200,000 active users, depending on feature requirements. Plan the migration before you hit that number, not after.

Option 2: Use a provider with predictable pricing

A small number of vendors price auth on a flat or per-tenant basis, not per user. The math here is different: your costs scale with how many customers you have, not how many users those customers have. For B2B SaaS this is usually the right shape - a customer with 50 users and a customer with 5,000 users are probably paying you similar amounts, so your cost line should match.

Option 3: Build and operate it yourself

Viable for teams with the security and operations discipline to do it well. Not viable for most. The true cost is not the code - it is the on-call rotation for brute-force attacks, the password reset flows, the audit log infrastructure, the MFA implementation, and the six months of compliance work before your first SOC 2 audit. Budget accordingly.

The Real Number

The question to ask a vendor before you sign anything: "what will I pay per month if I have 1,000 tenants, each with 100 users, once a year from now?" If the answer is anything other than a concrete dollar amount, you are about to enter a pricing trap. If the answer comes with an "it depends on your MAU," you are already in it.

LoginMe prices per tenant, not per MAU. If you have 1,000 tenants, you know what you are paying. If those tenants grow, you do not pay more. If you want to see the math, check the pricing page.