The real cost of hosted authentication

Hosted authentication pricing is a function of billable users, organisations, enterprise connections, feature gates, and support terms. The integration also creates recurring engineering work and a future migration surface. Those costs use different units, so they need separate lines in the model.

User units are not interchangeable

Clerk prices around monthly retained users, or MRUs. Its pricing page defines a retained user as someone who returns at least 24 hours after signing up. Auth0 publishes monthly active user tiers. WorkOS counts a user as active after an action such as sign-up, sign-in, or profile update during the calendar month. Google Cloud Identity Platform counts an account that signs in during the month as an MAU.

The same application can produce different totals under each definition. One-time sign-ups do not become Clerk MRUs, while signed-in accounts can count as MAUs elsewhere. Registered-user totals cannot substitute for either unit. A defensible estimate starts with authentication event data and reproduces each provider's published definition.

Published prices on 29 July 2026

Clerk's Hobby plan includes up to 50,000 MRUs per application. Pro is listed at $20 per month when billed annually, includes 50,000 MRUs, and charges from $0.02 per additional MRU before published volume discounts. The enhanced B2B Authentication add-on is listed at $100 monthly or $85 monthly when billed annually, with separate monthly retained organisation allowances and overages.

Auth0's B2C Free plan includes up to 25,000 MAUs. At the displayed 500-MAU tier, Essentials is listed at $35 per month and Professional at $240 per month. The plans differ in limits, attack protection, MFA, environments, support, and organisation features. Higher user, SSO, and enterprise requirements can move to custom tiers.

WorkOS lists AuthKit user management as free for up to one million active users, then $2,500 per additional million users per month. Enterprise SSO starts at $125 per connection in the first published tier. Custom domains, log streaming, audit-event retention, Directory Sync, and other enterprise products have separate prices.

Google Cloud Identity Platform publishes no-cost usage through 50,000 MAUs for email, phone, anonymous, and social providers, followed by tiered per-MAU pricing. SAML and OpenID Connect use a separate 50-MAU allowance and a published per-MAU rate. Phone and MFA usage also has per-message pricing by destination.

These figures are a dated snapshot, not constants. Store the pricing URL, review date, billing cadence, and currency beside each value. Quote-only features need a written quote rather than a zero in the spreadsheet.

Feature gates can dominate user pricing

A B2B product with 5,000 users may pay more for SSO connections, directory synchronization, custom organisation roles, audit retention, and support than for users. A consumer product may be driven by active-user and SMS volume. The plan comparison must use the smallest plan that contains the production requirements, not the smallest plan that supports email sign-in.

• Billable users under the provider's exact definition, separated by application and environment.
• Active organisations, members per organisation, roles, permissions, invitations, and verified domains.
• SAML, OIDC, and directory connections expected across the contract period.
• MFA methods, SMS destinations and volume, auth email volume, custom domains, and sender controls.
• Machine tokens, user-created API keys, audit retention, log streaming, support, and uptime commitments.

The application still owns integration code

A hosted provider operates the identity service. The application still validates HTTP input, transports sessions, enforces product authorization, protects provider credentials, renders account states, handles webhooks, and maps provider identifiers into product records. Recurring work includes SDK upgrades, schema or API changes, test environments, webhook replay, support tooling, and incident procedures.

Replication creates another cost. When product tables need local user, organisation, or role data, webhooks maintain a second model that can be late, duplicated, or delivered out of order. The integration needs idempotency, reconciliation, and a documented source of truth for each field.

Migration cost starts with coupling

Provider replacement can require identity export, identifier mapping, password-hash compatibility, session replacement, callback changes, webhook removal, UI changes, and customer SSO reconfiguration. Passwords that cannot be imported need a sign-in migration or reset. Active sessions need an explicit cutover. Provider identifiers referenced throughout product tables expand the rewrite.

The migration estimate should inventory every SDK, route, cookie, callback, webhook, provider table, and external connection. It should distinguish records that can be exported from behavior encoded only in the provider configuration. That estimate is part of the current architecture cost even when no migration is scheduled.

Self-hosting changes the cost center

A self-hosted library removes the hosted provider's user and feature invoice. The application instead pays for database capacity, backups, migrations, rate-limit storage, monitoring, security updates, abuse response, and outbound email or SMS. Authentication availability becomes part of the application's own service objective.

Own Auth is fully open source and has no per-user library charge. It runs in the backend and stores source auth records in Postgres. Applications can connect their own email and SMS providers.

A comparable annual model

1. Calculate each provider's billable user and organisation counts from representative events.
2. Select the plan containing every required production feature and environment.
3. Add published overages, connections, messages, domains, logs, support, and quoted products.
4. Add implementation, annual maintenance, incident ownership, and the current migration estimate.
5. For self-hosting, add database, delivery, observability, maintenance, and security-review costs.
6. Run current, growth, and spike scenarios using the same twelve-month period.

The output should show annual cash cost, engineering days, and the billing assumptions separately. Dividing the total by retained users, customer organisations, or recurring revenue makes the tradeoff visible without pretending that MRU, MAU, SSO connections, and engineering time are the same unit.