The Decision You Only Make Once (and Regret for Years)
Auth is one of the few infrastructure choices that's genuinely expensive to reverse. You don't swap identity providers the way you swap a logging library — every user has a session, a password hash (or lack of one), MFA enrollment, and a dozen third-party integrations wired to your JWTs. So when a team asks "which auth service should we use," the honest answer isn't "it depends," it's "it depends on exactly these four things, and here's how each option fails you."
I've now shipped production apps on Auth0, Clerk, Supabase Auth, and Firebase Auth. Here's where each one actually breaks, not the marketing-page version.
Setup Speed and Day-One DX
Clerk wins this outright. Drop in <SignIn /> and <UserButton />, and you have a working auth flow with prebuilt, themeable UI in under 30 minutes — social login, MFA, and session management included, no redirect-based hosted page required unless you want one. It's clearly built by people who shipped a SaaS app themselves and got tired of gluing Auth0's SDK to a design system.
Firebase Auth is nearly as fast if you're already in the Firebase/GCP ecosystem — signInWithPopup and you're done — but the moment you need custom UI, you're hand-rolling forms against the SDK, because Firebase never shipped real prebuilt components, just a dated "FirebaseUI" library nobody maintains anymore.
Auth0 is the slowest of the four to get right, not because it's hard, but because it has three different ways to do everything (Universal Login vs. embedded login, Rules vs. Actions vs. the older Hooks) and picking wrong costs you a rewrite later. Supabase Auth sits in between: fast if you're already using Supabase for Postgres, painful if you're not, because you inherit the whole Supabase client just to get a session token.
The Pricing Cliff Nobody Reads Until It's Too Late
This is where the real decision gets made, and it's rarely about the sticker price.
Auth0's free tier caps out fast, and the jump to a paid plan isn't gradual — it's a cliff at a fixed MAU count, after which per-user costs escalate quickly, especially once you add MFA, custom domains, or Organizations (B2B multi-tenant support) as separate line items. I've seen teams get a surprise five-figure invoice not from usage growth but from turning on a feature they assumed was included.
Clerk's free tier is genuinely generous for early-stage products, and its pricing scales more linearly — you feel the cost coming before it hits. Firebase Auth is the cheapest at real scale for pure B2C: it's priced per verification (phone/SMS) or effectively free for email/social, since Google isn't trying to monetize auth itself, just the rest of GCP around it. Supabase Auth is bundled into Supabase's project pricing, which means it's cheap in isolation but you're really paying for the whole platform — fine if you wanted Postgres + Auth + Storage together, wasteful if you only wanted auth.
The practical rule: if you can forecast your MAU growth curve with any confidence, price out Auth0 and Clerk at 2x your 12-month projection before committing, not at today's numbers. That cliff is the thing that actually changes vendor decisions mid-flight.
Multi-Tenancy and B2B Orgs: Where Three of the Four Fall Short
If you're building B2B SaaS with organizations, roles, and per-tenant SSO, Auth0 is the only one of the four with this genuinely built in and battle-tested — Organizations, SAML/OIDC federation per tenant, and enterprise connections are first-class, not bolted on. This is the single strongest reason to pick Auth0 over the alternatives, and it's also the reason its pricing model exists the way it does — you're paying for compliance surface area, not just login forms.
Clerk added Organizations support later and it's solid for straightforward multi-tenant B2B, but it doesn't yet match Auth0's depth on enterprise SSO federation across many customer IdPs. Supabase Auth has no native organization/multi-tenancy concept at all — you build it yourself with Postgres Row Level Security and a tenant_id column, which is powerful if you're comfortable owning that logic, and a real gap if you assumed the vendor handled it. Firebase Auth is squarely B2C-shaped; retrofitting B2B tenancy onto it is possible but fights the grain of the product the whole way.
Customization Depth vs. Lock-In Risk
Auth0's Actions (its post-login/pre-token hook system) let you inject arbitrary logic into the auth flow — enrich a JWT with data from an external API, block logins based on custom risk rules, sync to a CRM on signup. It's the most extensible of the four, and also the easiest one to over-invest in: every Action you write is logic that doesn't move with you if you ever migrate off Auth0.
Supabase Auth's equivalent is Postgres functions and triggers, which is arguably less lock-in because it's standard SQL you could point at any Postgres instance — you're locked into Postgres, not into Supabase specifically. Clerk exposes webhooks and a metadata API that cover most customization needs without the same depth of in-flow logic injection. Firebase Auth is the most locked-in of all four in practice, not because of its extensibility model, but because teams that adopt it usually adopt Firestore and Cloud Functions alongside it, and untangling auth from the rest of the GCP stack later is a multi-week project, not a config change.
Where Each One Actually Wins
Pick Auth0 if you're building B2B software that will eventually need SAML/OIDC federation with enterprise customers' IdPs, or you're in a regulated space where SOC 2/audit-log depth matters more than setup speed — and budget for the MAU cliff before it surprises you.
Pick Clerk if you're a small team shipping a B2C or lightweight-B2B product and want production-grade auth UI without building it yourself — it's the best default for most new SaaS products today.
Pick Supabase Auth only if you're already committing to Supabase for your database — the auth piece isn't strong enough to justify adopting the platform on its own, but it's genuinely good once you're there.
Pick Firebase Auth if you're mobile-first, already on GCP, and your user base is overwhelmingly consumer rather than organizational — it's the cheapest option at scale, but you're trading multi-tenant flexibility for that price.
The mistake I keep seeing isn't picking the "wrong" one of these four — all four are production-grade. It's picking based on the login-page demo instead of the MAU pricing table and the org-support column, which is exactly the part that's expensive to discover six months in.
Top comments (0)