Clerk vs Auth0 vs NextAuth for SaaS

Auth is the layer founders spend the least time choosing and the most time regretting. Every option has a five-minute quickstart, so the decision gets made in an afternoon — and two years later you're migrating password hashes under a live product because your first enterprise prospect asked for SAML. We listed the options in our SaaS MVP tech stack guide; this is the longer argument behind that one-line recommendation.

Which auth provider should you use for your SaaS?

For most SaaS products in 2026, use Clerk if you want to ship fastest, NextAuth (Auth.js) if you want zero vendor cost and full control, and Auth0 or Okta only when enterprise buyers are contractually forcing your hand. If you're already on Supabase, Supabase Auth is the obvious answer — it's included, it's Postgres-native, and one fewer vendor is worth a slightly less polished sign-in screen.

The real decision isn't a feature comparison. It's how much of the auth surface do you want to own? Clerk owns nearly all of it and charges you. NextAuth owns almost none of it and hands you the rest. Everything below is downstream of that trade.

The four options, side by side

| | Clerk | Auth0 / Okta | NextAuth (Auth.js) | Supabase Auth | |---|---|---|---|---| | Pricing model | Free to ~10k MAU, then per-MAU | Free tier, then per-MAU + feature tiers | Free, open source | Included in your Supabase plan | | Time to ship | Hours | Days | Days | Hours (if already on Supabase) | | UI/UX out of box | Best in class — full components | Hosted pages, functional but dated | None — you build every screen | Basic components | | SSO / SAML | Paid add-on, works well | The reason to pick it | Build it yourself | On paid tiers | | Self-host / lock-in | No self-host; real lock-in | No self-host; heavy lock-in | Your database, your code, none | Open source, self-hostable | | Best for | Speed to market, B2C and early B2B | Enterprise B2B with compliance demands | Cost control, design control | Anyone already on Postgres/Supabase |

Two rows carry the decision. UI/UX out of box is where Clerk earns its fee: sign-in, sign-up, MFA, organisation switching, invitations — real components, not a styled form, and two to three weeks of work you don't do. Self-host / lock-in is where NextAuth earns its place: sessions and users live in your own Postgres, so leaving costs nothing because there's nothing to leave.

What does auth actually cost as you grow?

Almost nothing until you cross a monthly-active-user threshold, then a lot all at once — the per-MAU cliff is the gotcha nobody prices in. Every provider's free tier is generous enough that auth costs £0 through your entire MVP, which is exactly why founders never model it.

| Users (MAU) | Clerk | Auth0 | NextAuth | Supabase Auth | |---|---|---|---|---| | 1,000 | £0 | £0 | £0 | £0 (free tier) | | 10,000 | £0–£20 | £0 | £0 | ~£20 (Pro plan) | | 50,000 | ~£200+ | ~£600+ | £0 | ~£20–£100 | | Enterprise SSO | +£40–£80 per connection | Enterprise quote, often £1k+/mo | Your engineering time | Higher tiers |

The pattern matters more than the exact figures, which move every year. Free tiers end at a user count you'd be delighted to reach; past it, cost scales linearly with growth forever. At 50,000 MAU, Clerk is a line item you notice and Auth0 is one your finance lead asks about. NextAuth stays at zero and instead costs you the engineering hours to maintain what the others hand you. Auth0's jump out of free is the steepest of the four, and its B2B and enterprise features sit behind tiers priced for companies with procurement departments. If you expect consumer-scale user counts at low revenue per user, per-MAU pricing is the wrong shape for your business — plan for NextAuth or Supabase Auth from the start.

Keep it in proportion, though: at MVP scale this is one of the smaller lines in your monthly bill. We break the whole picture down in what it costs to maintain a SaaS — auth is rarely the number that hurts.

When do you need SSO/SAML?

When an enterprise buyer puts it in a security questionnaire — and almost never before. SSO is a sales unblocker, not a product feature. No user has ever churned because they had to type a password; plenty of six-figure deals have stalled because the buyer's IT team requires every vendor to sit behind Okta or Entra ID.

Signals you're close to needing it:

• Prospects are sending security questionnaires or vendor-review forms
• Deals above roughly £20k ACV, where IT gets a veto
• Buyers in regulated sectors — financial services, healthcare, government
• Anyone asking about SCIM (automated user provisioning and deprovisioning)

Until one of those is real, SSO is a feature built for an imaginary customer. When the first serious deal does ask, you have options: Clerk and Supabase both sell SAML connections, Auth0 has the deepest support, and WorkOS exists specifically to bolt enterprise SSO onto a product that already has everything else — usually cheaper than migrating your whole auth layer for one requirement.

So don't buy Auth0 on day one to avoid a migration on day five hundred. That's years of cost and complexity for optionality you may never use, and adding an SSO vendor later is a week of work, not a rebuild.

Should you ever build your own auth?

No. Not "rarely" — no. This is the one layer of your stack where the downside is unbounded and the upside is a saved subscription.

Everything on this list is something we have found in inherited codebases written by competent engineers:

• Password reset tokens that never expire, or are guessable
• Session fixation — the session ID doesn't rotate after login
• No rate limiting on login, so credential stuffing runs unimpeded
• OAuth state parameters generated but never verified, enabling CSRF
• Passwords hashed with a fast algorithm instead of bcrypt or argon2
• Email enumeration via different responses for "wrong password" and "no such user"

Each is individually easy to avoid and collectively almost impossible to get right alongside building your actual product. And the list keeps growing: passkeys, MFA recovery, device management, breached-password checks, bot detection. A provider ships those; you'd have to write them, then keep writing them.

The economics are absurd laid out plainly. Clerk is roughly £20 a month at MVP scale. A single breach costs customer trust, a disclosure obligation, potential ICO involvement under UK GDPR, and every enterprise deal in your pipeline. Nobody has ever won a customer by writing their own session handling.

The one legitimate middle ground is a library like Lucia or Better Auth, where you own the implementation but not the security primitives — defensible for a team with real security experience and a specific need, but still more work than NextAuth.

Our default

For the SaaS MVPs we build, the default is Clerk on Next.js, for one honest reason: it removes two to three weeks of UI work from an eight-week build. Sign-in, sign-up, MFA, organisations, invitations and the user profile all arrive working and reasonably attractive. On a fixed-price engagement, weeks are the currency that matters — part of why we can quote fixed-price builds with confidence.

We deviate in three situations, all common enough to state plainly:

When the client is already on Supabase, we use Supabase Auth. Row-level security keyed to the authenticated user is genuinely cleaner when auth and data share a database, and it's one fewer vendor. We make the broader backend case in Supabase vs Firebase.

When the product is consumer-scale — free tiers, hundreds of thousands of sign-ups, low revenue per user — per-MAU pricing is structurally wrong, and we use NextAuth with a Postgres adapter.

When the sign-in experience is part of the brand and the client wants pixel control over every screen, NextAuth again. Clerk's components are themeable but not infinitely so.

What we never do is roll our own, or put a pre-revenue startup on Auth0 for an enterprise pipeline that doesn't exist yet. All of this assumes Next.js as the frontend, which is its own decision — covered in React vs Next.js.

Frequently asked questions

Is Clerk worth paying for over NextAuth?

Yes, for most teams on a deadline — you're buying two to three weeks of UI and flow engineering for roughly £20 a month at MVP scale. NextAuth handles the protocols correctly and costs nothing, but it deliberately ships no interface: every sign-in page, password reset flow, MFA enrolment screen, organisation invite and profile editor is yours to design, build and maintain forever. Clerk hands you all of it working. The calculation flips at consumer-scale user counts, where per-MAU pricing eventually exceeds what those weeks were worth, or when the sign-in screen genuinely has to be yours.

Can you migrate from one auth provider to another later?

Yes — budget one to two weeks, and do it before you have serious scale. The mechanics are well-trodden: most providers import bcrypt password hashes directly, and OAuth identities re-link by email address. The work is in the surrounding code — every session check, middleware guard, webhook and role-permission lookup touches the provider's SDK — plus a careful cutover so nobody is logged out mid-session. Easier than a database migration, harder than swapping email providers: worth ten minutes of thought, not three weeks.

Does NextAuth work with the Next.js App Router?

Yes — Auth.js v5 was rewritten specifically for the App Router, with a single config file and server-component-friendly session access. The migration from the older v4 API tripped a lot of teams up, and plenty of tutorial content still shows the outdated pattern, so check that anything you copy targets v5. On a new build, start from v5 with a Postgres or Prisma adapter — a well-documented path that keeps every user record in a database you control.

What about Firebase Auth or AWS Cognito?

Both are viable, and both are usually the wrong shape for a Next.js SaaS. Firebase Auth is mature and free at reasonable scale, but it pulls you into Google's ecosystem and pairs most naturally with Firestore rather than Postgres. Cognito is cheap and deeply integrated with AWS, but its developer experience is widely considered the weakest of the mainstream options: configuration is fiddly, the hosted UI is dated, and customisation fights you. Either is defensible if you're already committed to that cloud. Choosing freely, the four compared above are better answers.

The bottom line

Pick by constraint, not by feature list. Shipping fast → Clerk. Already on Supabase → Supabase Auth. Cost or design control matters most → NextAuth. Enterprise buyers with SAML in the contract → Auth0, or bolt WorkOS onto what you have. And under no circumstances, at any stage, build it yourself.

Auth is infrastructure: the right choice is the one you stop thinking about a week after wiring it in, so your attention goes back to the part of the product customers actually pay for.

Want the auth layer chosen around your buyers and your budget rather than a default? Book a free scoping call — we'll spec the right stack for your product and quote it fixed-price.