Monthly active user pricing looks reasonable on a pricing page. You pay for people who actually use the product, not for dormant rows in a database. Nobody argues with that on day one.
The problem arrives later, and it arrives suddenly.
A marketing campaign lands, a partner integration goes live, a seasonal peak hits, and your identity bill triples while your revenue does not.
Worse, the spike is often not caused by paying customers at all. It is caused by traffic that authenticated once and never came back.
This article breaks down why the MAU model behaves badly under load, what to measure before you commit to a vendor, and which questions actually surface the cost curve.
What You Are Actually Paying For
Start with what an identity provider does, because the billing metric rarely maps cleanly onto it.
Under RFC 6749, OAuth 2.0 introduces an authorization layer that separates the client from the resource owner, issuing an access token that denotes a specific scope, lifetime and set of access attributes.
Notice what is being counted there. Tokens, scopes and lifetimes. Not users.
Federation adds another layer. NIST guidelines on federation and assertions describe how an identity provider conveys authentication attributes, and optionally subscriber attributes, to a number of separately administered relying parties, and note that relying parties may use more than one identity provider.
Again, no natural unit called a monthly active user appears anywhere in the protocol.
MAU is a commercial abstraction layered on top of a technical system that counts something else entirely. That gap is where the surprises live.
The definition also varies by vendor, and the variance is expensive:
- Does a user who logs in once on the last day of the month count for that month?
- Does a token refresh count as activity?
- Does a machine-to-machine client count as a user?
- Does a user who exists in three tenants count once or three times?
- Do anonymous or guest sessions count?
Four of those five answers can double a bill without a single additional human being touching the product.
Why Teams Start Looking for a WorkOS Alternative
The migration conversation almost never starts with features. It starts with a finance question that engineering cannot answer.
Ory, as a WorkOS alternative, publishes a side-by-side comparison and the pricing section is the part worth reading closely. It argues that alternatives charge for every user while Ory charges only for average daily users, and it makes deployment flexibility and data localization part of the same argument.
Treat those as vendor claims rather than benchmarks, and then go verify them against your own numbers. That is the useful exercise regardless of which vendor you end up choosing.
The underlying distinction is real, though, and it is worth understanding independently of any product.
Peak-based billing charges you for the worst hour of your month. Average-based billing charges you for the typical day. If your traffic is smooth, the two converge. If your traffic is spiky, they diverge enormously.
Here is the same workload under both models:
| Scenario | Peak day actives | Typical day actives | What you get billed on |
|---|---|---|---|
| Steady SaaS product | 12,000 | 10,000 | Little difference |
| Product launch month | 90,000 | 11,000 | Roughly 8x difference |
| Seasonal retail | 140,000 | 9,000 | Roughly 15x difference |
| B2B with a large new tenant | 45,000 | 12,000 | Roughly 4x difference |
The first row is the one every pricing page is designed around. The other three are the ones that actually break budgets.
The Spike You Did Not Plan For
Traffic surges are not always growth. Sometimes they are load.
Anyone who has run a public API knows the pattern. RFC 6585 defines the 429 status code as indicating that a user has sent too many requests in a given amount of time, and notes the response may include a Retry-After header telling the client when to try again.
Rate limiting exists precisely because request volume is bursty and unpredictable. Identity endpoints are subject to exactly the same bursts.
Credential stuffing attempts, bot registrations, retry storms from a misconfigured mobile client, a partner batching authentication calls at midnight: none of these represent revenue, and under some counting models all of them can inflate a user metric.
Ask directly how a vendor handles that. Whether failed authentication attempts count, whether blocked traffic counts, and whether you can be billed for an attack.
Data Residency Changes the Math Too
There is a second cost dimension that rarely appears in the headline number.
Identity data is personal data by definition. Where it lives is a legal question, not just an architectural one.
Under EU law, Chapter V of the General Data Protection Regulation, covering Articles 44 to 50, lays down the rules for transferring personal data to third countries or international organizations, as set out in EU regulation documents applying that framework.
If your identity provider stores user records in a region you did not choose, satisfying those rules becomes a contractual negotiation rather than a configuration setting.
Vendors that offer self-hosting, regional deployment or on-premises options let you answer the residency question yourself. Vendors that do not will answer it for you, and the enterprise deal you lose because of it is a real cost that never shows up on the invoice.
Questions That Surface the Real Cost Curve
Before signing anything, get written answers to these:
- What exactly triggers a billable active user? First login, any token issuance, or any API call.
- Is the count based on peak or average? This single answer explains most bill shock.
- How are machine-to-machine clients counted? Service accounts can outnumber humans in a mature system.
- How are multi-tenant users counted? One human across five customer organizations may bill as five.
- What happens during an attack? Ask whether blocked or failed attempts are excluded.
- What is the overage rate? And whether it is charged automatically or requires a plan change.
- Where does the data live, and can you move it? Both the region and the export path.
- What does leaving look like? Bulk export of users, including password hashes, in a documented format.
That last question is the one people skip, and it is the one that determines whether pricing changes three years from now are a negotiation or an ultimatum.
The Practical Takeaway
Model your identity cost against your worst month, not your average one. Pull twelve months of authentication logs, find the peak day, and run the vendor's formula against it.
If the number frightens you, that is not a reason to panic. It is a reason to prefer a model priced on typical load, or an architecture you can host yourself when the economics stop working.
Identity is infrastructure. Infrastructure priced on your least representative day is infrastructure you do not fully control.
