Clerk vs Auth0: Which Authentication Platform Fits Your Team? - Part 3

Clerk vs Auth0: which authentication platform should you choose? - Part 3

This is the final part of our three-part comparison between Clerk and Auth0. Part 1 covered developer experience and architecture, and Part 2 explored enterprise capabilities. In this part, we break down pricing models (MAU vs MRU), the migration path, and provide our final verdict.

Pricing: per-MAU vs. per-MRU, and what's bundled

Every figure below is dated (June 2026), sourced inline, and paired with the counting methodology behind it.

How each platform prices and counts users

The single most misleading move in any comparison is putting Auth0's per-MAU price next to Clerk's per-MRU price as if they count the same population. They do not.

Auth0 bills per Monthly Active User (MAU)⁠: a user who logs in or refreshes a token at least once in a calendar month. A user who signed up but never logged in is not an MAU, and — importantly — a SCIM-provisioned user who never logs in is not an MAU either⁠. (The occasionally repeated claim that inactive provisioned seats inflate the Auth0 bill is false: MAU counts only authenticating users.) Counting is per tenant, so one human active across N tenants counts as N MAU.

Clerk bills per Monthly Retained User (MRU): a user who returns at least one day after signing up. Clerk's "First Day Free" model means sign-up-and-bounce users are never billable. For an app with meaningful trial or bounce traffic, that structurally lowers the billable count relative to a naive MAU comparison.

The honest consequence: comparing list per-unit prices alone is misleading, because MAU and MRU count different things. It is a counting-methodology difference rather than a discount — but a real one, and it favors Clerk for high-signup, high-bounce products.

What's included vs. what costs extra

A fair "what do you pay to reach enterprise" view, with the February 2026 changes folded in. Auth0 gates or charges several capabilities through tiers and add-ons: Enterprise-MFA factors⁠ are a $100/mo add-on on Essentials (included on Professional), Adaptive MFA and Credential Guard and Highly Regulated Identity are Enterprise add-ons, production FGA is an Enterprise contract, and additional enterprise connections are $100/mo each. Its February 2026 B2B upgrade, to its credit, moved self-service SSO and SCIM onto the free B2B plan.

Clerk bundles organizations into every plan and includes SCIM free with each enterprise connection; the paid lever is the B2B Authentication add-on ($100/mo, or $85/mo billed annually), which unlocks org-linked connections, unlimited org members, verified domains, and custom roles and role sets. Enterprise connections are one-free-then-metered (covered next).

SSO and enterprise connection pricing

For per-connection economics: Clerk includes one enterprise connection on both Pro and Business, then meters additional connections at $75 each (connections 2-15), $60 (16-100), $30 (101-500), and $15 (501+). The historical flat $50-per-connection fee was removed in November 2024 and should not be cited. Auth0 includes one enterprise connection on the free B2B plan, three on B2B Essentials, and five on B2B Professional, then charges $100/mo per additional connection⁠ up to a maximum of 30.

So at low connection counts the included allotments matter most (Auth0 B2B Professional includes five; Clerk includes one and meters the rest at $75), while Clerk's metered tiers become markedly cheaper per connection as the count grows into the hundreds.

Cost at scale and the crossover

The common driver behind this comparison is the worry that Auth0's per-MAU pricing climbs steeply as an app grows. The data supports a nuanced version of that. Auth0's self-serve, publicly listed pricing runs into the tens of thousands of MAU — B2B plans hit "Contact us" around 20,000 MAU, and B2C self-serve tops out at 50,000 MAU (Essentials $3,500) — so at six-figure volumes (100,000 MAU and up) Auth0 pricing is no longer published and becomes an Enterprise sales quote. Clerk, by contrast, publishes per-MRU pricing all the way to 1,000,000 and beyond.

That transparency asymmetry is the real, defensible point: in the self-serve range the public gap is large, and above the self-serve ceiling — roughly 20,000 MAU for B2B, 50,000 for B2C — Auth0 leaves public pricing entirely, so no public crossover can be drawn at the top; both vendors negotiate enterprise pricing there. The worked scenarios below show the climb within the self-serve band using current, dated list prices, which is a firmer basis than the widely repeated "growth penalty" figures that circulate for Auth0 without primary sourcing.

Worked cost comparison

Two scenarios make the model concrete. Every assumption is labeled and dated (June 2026). These are list prices only; Enterprise and custom pricing is negotiated. Both scenarios assume every raw user is billable, which overstates Clerk's real cost because true MRU is lower than MAU whenever there is sign-up-and-bounce traffic.

Scenario A is basic consumer auth with MFA enabled as the production-bar floor (an apples-to-apples assumption — MFA requires a paid plan on both vendors):

Clerk Pro is a flat $25 through 50,000 MRU, while Auth0 Essentials climbs in discrete MAU tiers that track $35 + (MAU − 500) × $0.07 at the published tier points. Auth0's Free tier genuinely covers up to 25,000 MAU at $0 — but with no MFA, so the moment MFA is your production bar, Essentials becomes the floor. (Clerk's free Hobby tier likewise has no MFA, which is why both sit at $0 only without MFA.) Above 50,000 MAU, Auth0's B2C self-serve pricing ends and the plan becomes an Enterprise quote.

Scenario B is B2B SaaS with five enterprise SSO connections plus organizations:

At around five connections and low volume, Auth0 B2B Essentials with two extra connections and Clerk with its B2B add-on and four metered connections land close. As volume grows, Clerk's MRU base plus flat add-on stays publicly priced to 1,000,000 and beyond, while Auth0 moves to a sales quote past the self-serve range. The public-pricing gap is real in the self-serve band; beyond it, both vendors negotiate, so there is no public Auth0 figure to compare against at six-figure volume.

Migrating from Auth0 to Clerk

Migration from Auth0 to Clerk is well-tooled but not fully self-serve, and the honest shape matters. You export user profiles from Auth0 through the Management API export job (JSON or NDJSON; the standard bulk export does not include password hashes). To preserve passwords so users are not forced to reset, you request a password-hash export from Auth0 Support⁠ — a support-ticket dependency available only on paid plans (the free plan has community support only, no tickets). Auth0 hashes passwords with bcrypt for users who sign up directly, so the export is bcrypt in the typical case; users that were themselves imported into Auth0 under a different algorithm (Auth0 also accepts argon2, pbkdf2, scrypt, and others on import⁠) and have not signed in since can instead export as a non-bcrypt custom_password_hash.

With the hashes in hand, merge them into your exported profiles and convert the result to a single JSON array — the CLI reads a JSON array or CSV, not the NDJSON the export job emits — then import into Clerk using the official open-source migration CLI (github.com/clerk/migration-tool⁠):

bun migrate -y -t auth0 -f users.json

The transformer maps Auth0 fields to Clerk: it imports each exported hash as bcrypt (the format Auth0 uses natively), the Auth0 user_id becomes Clerk's externalId, user_metadata becomes publicMetadata, and app_metadata becomes privateMetadata. The -t flag selects the source format (one of clerk, auth0, authjs, firebase, or supabase), and a partial run resumes with --resume-after <userId> (short alias -r). After import, validate a single test user end-to-end, then cut over. Because Clerk bills per MRU, dual-running during a trickle (just-in-time) migration stays inexpensive.

The honest effort assessment: the import is well-tooled, but the password-hash export is a paid-plan support-ticket step, and RBAC and organization structure do not carry over automatically — you re-model those by hand. The auth0 preset assumes bcrypt, which covers the common case; for the rest, Clerk's import API accepts a broad password_hasher set (argon2, pbkdf2, scrypt, and more, with insecure schemes transparently upgraded to bcrypt on first sign-in), so any non-bcrypt custom_password_hash rows can be imported through that API directly with the matching hasher — the CLI's auth0 preset does not translate them. It is a smooth path, not a one-click one.

When Auth0 is the better choice

Auth0 earns the decision in several real situations:

• You need deep, scriptable extensibility synchronously inside the auth pipeline (Actions: block, redirect-and-resume, enrich tokens from external APIs at issuance) or the largest catalog of prebuilt connections and marketplace integrations.
• You need relationship-based fine-grained authorization (Auth0 FGA) for graph-shaped permissions in complex, B2B, or AI and RAG applications.
• You need advanced or regulated-industry security: Adaptive MFA, Credential Guard, or Highly Regulated Identity (FAPI, strong customer authentication) for finance, banking, or healthcare.
• You want the broadest compliance and certification footprint (ISO 27001/27017/27018, PCI DSS, CSA STAR, FAPI) and deployment options (multiple regions, single-tenant Private Cloud, data residency), plus the longest enterprise track record.
• You are consolidating customer and workforce identity under one vendor, or you already run Okta.
• You are building on a non-JavaScript stack — Spring Boot, ASP.NET Core, or Laravel, where Auth0 ships official framework SDKs and Quickstarts while Clerk offers backend API SDKs (Java, C#, PHP, Python, Go) rather than framework-native integrations, or Angular, where Clerk's SDK is community-maintained — or on Flutter, where both vendors ship an official SDK but Auth0's is production-GA against Clerk's pre-1.0 beta. Ruby is the exception: Clerk's Ruby SDK ships Rails and Sinatra integrations, not just a Backend API wrapper.
• You have a heavily customized existing Auth0 investment whose migration cost outweighs the benefit of switching.

Auth0 is also building real forward-looking strength in AI agent authentication: Auth0 for Agents⁠ adds Token Vault (generally available) for connecting agents to third-party APIs, plus CIBA for asynchronous, human-in-the-loop authorization and FGA for retrieval-augmented generation. Clerk offers general M2M tokens but no direct equivalent to that agent-auth suite, so for agent-heavy products Auth0 currently leads.

When Clerk is the better choice

Clerk fits a different center of gravity:

• Product teams that value developer experience and speed-to-market, and want to own very little custom auth code.
• Teams that want embedded, branded auth UI — with optional fully headless hooks — instead of redirecting users to a hosted page.
• B2B SaaS that wants native organizations, roles, and per-org SSO with prebuilt UI bundled rather than assembled.
• Teams on current frameworks (Next.js 16, React, React Router v7, Astro, TanStack Start, Expo) that want first-class, framework-native SDKs.
• Teams that want predictable, retention-based (MRU) pricing that excludes sign-up-and-bounce users and stays publicly priced to 1,000,000 and beyond.
• Teams operating in the self-serve volume range that want bundled B2B features without per-feature add-ons climbing the bill.

For most modern product teams, this is where the evidence lands.

Conclusion

The through-line is consistent. Auth0 is the mature, extensible, configuration-driven incumbent: a hosted, redirect-based login plus a synchronous Actions pipeline, the broadest catalog of connections, certifications, and deployment options, and a decade-plus enterprise track record backed by Okta. Clerk is the modern, developer-experience-first product: embedded components, framework-native SDKs, native bundled B2B organizations, and retention-based pricing.

Two framings carry most of the decision. First, how each is built and consumed — embedded components rendered in your app versus a redirect to a hosted page. Second, how each prices and counts users — Clerk per MRU (excluding sign-up-and-bounce traffic, published to 1,000,000-plus) versus Auth0 per MAU (self-serve into the tens of thousands, then an Enterprise quote) — plus what each bundles versus charges as an add-on.

So the fair verdict: choose Auth0 when you need its synchronous extensibility, relationship-based fine-grained authorization, regulated-industry security, the broadest compliance and deployment footprint, or Okta consolidation. Choose Clerk when you are a product team prioritizing developer experience, embedded UI, native B2B organizations, modern framework SDKs, and transparent retention-based pricing. Re-run the cost model with your own numbers before deciding — every figure here is dated and sourced inline, and both products change pricing often.

Frequently asked questions

In this series

1. Clerk vs Auth0: Which Authentication Platform Fits Your Team?
2. Clerk vs Auth0: Which Authentication Platform Fits Your Team? - Part 2
3. Clerk vs Auth0: Which Authentication Platform Fits Your Team? - Part 3 (you are here)