Choosing Authentication for a New SaaS in 2026: Clerk, Auth.js, Supabase Auth, Better Auth, and When to Self-Host

Authentication is the least exciting part of building a SaaS product. Then it breaks, and it is the only thing that matters. Or the user count crosses a threshold, the monthly bill jumps, and a decision someone made in an afternoon becomes a six-month migration.

We make this decision on client projects regularly, and the honest answer is that there is no single right choice. There is a right choice for a given stack, a given growth profile, a given set of enterprise requirements, and a given tolerance for vendor lock-in. This post lays out how we think through it: the five real options in 2026, what each is good and bad at, the cost math at scale, and the decision logic we actually use.

It is written for the technical founder or product team picking auth for a new build, or weighing whether the auth decision made early is still the right one.

The five options

In 2026, five approaches cover almost every SaaS project.

Clerk is a managed authentication platform built for modern React and Next.js apps. You drop in pre-built components, wire up environment variables, and have working auth, including social login, magic links, passkeys, MFA, and organization management, in well under an hour.

Auth.js (formerly NextAuth, rebranded with v5) is the open-source, self-hosted library that dominates open-source examples. It is free, framework-integrated, and gives you total control, at the cost of building the pieces it does not include.

Supabase Auth is authentication bundled into the Supabase platform. If you are already using Supabase for your Postgres database, auth comes included, and it integrates at the database level through Row Level Security.

Better Auth is the newer open-source, self-hosted, framework-agnostic library that gained significant traction through 2025 and 2026. It ships with built-in 2FA, passkeys, organizations, and RBAC, the pieces Auth.js makes you build yourself.

Custom build is rolling your own on top of primitives. Rarely the right call, but there is a narrow set of cases where it is, and it is worth knowing where the line is.

What each one is good and bad at

Clerk

The strongest developer experience in the category. The pre-built <SignIn /> component includes email/password, social OAuth, magic links, passkeys, MFA, and CAPTCHA with no custom UI. Organization and team management, the multi-tenant feature most B2B SaaS needs, is first-class. For a Next.js SaaS that wants auth working today and values engineering time over cost, Clerk is hard to beat on speed.

The tradeoffs are cost at scale and lock-in. Clerk charges per active user above its free tier, and a high-growth consumer app can see the monthly bill climb fast. Clerk stores user data on its infrastructure, so migrating away later means exporting users and reimplementing flows. And there is no self-hosting option, which rules it out for on-premises or air-gapped requirements. Clerk repriced in February 2026 and the free tier is more generous than it was, which softens the early-stage cost concern, but the at-scale math still deserves a look before you commit.

Auth.js

Free forever as a library, the largest ecosystem, and total control. If you want to own every part of the auth flow and you have the engineering capacity to build and maintain it, Auth.js gives you that. v5 added Edge runtime support and better server action integration.

The cost is the pieces it does not include. There is no built-in 2FA, no built-in passkeys, no built-in organizations, no built-in RBAC. You implement all of these yourself or pull in additional libraries. "Free" is real for the library and misleading for the total: a senior developer's time building a custom auth UI, handling edge cases, wiring email verification, and maintaining all of it has a real cost. For a solo founder, that time is often better spent on the product.

Supabase Auth

If you are already on Supabase for your database, this is close to a default. Auth is included in a platform you are already paying for, and the Row Level Security integration is genuinely elegant: you write a policy once, like restricting rows to where the user ID matches the authenticated user, and the database enforces authorization on every query. No middleware, no per-endpoint permission checks. The free tier is the most generous of the managed options, comfortably covering most MVPs.

The catches: using Supabase Auth without the rest of Supabase defeats the purpose, it is tightly coupled to the platform. The pre-built UI components are basic, well short of Clerk's polish. And enterprise SSO is limited; Supabase supports OIDC connections but lacks the deep SAML configuration and enterprise identity provider management that closing enterprise B2B deals often requires.

Better Auth

The genuine new contender. Better Auth is framework-agnostic, integrates with any database through Drizzle or Prisma adapters, and ships with the features Auth.js makes you build: 2FA, passkeys, organizations, RBAC. It is open-source and self-hosted, so there is no per-user vendor bill and no vendor data lock-in. Your only costs are the database and email provider you are already paying for.

The tradeoff is that it is newer. The ecosystem, the volume of examples, the depth of community answers for obscure edge cases, is smaller than Auth.js or the managed platforms, though it grew quickly. For a team comfortable self-hosting auth and wanting modern features without a per-user bill, Better Auth is a strong 2026 choice in a way it was not two years ago.

Custom build

Build your own only when authentication is genuinely your core product differentiator, you have a dedicated security team with real depth, you have requirements no platform addresses, and you have a 12-month-plus timeline tolerance. For everyone else, custom auth is a way to spend a quarter rebuilding something that exists, and to take on the security liability of getting session management, token handling, password storage, and account recovery exactly right. The security consequences of getting any of those wrong are severe. The bar for "build it yourself" is high and most projects do not clear it.

The cost math at scale

The decision often comes down to what happens after the first few thousand users, so here is the shape of it.

The managed platforms charge per active user above a free tier. Clerk's free tier became more generous in February 2026, which covers the critical early-growth phase, but above it the per-user cost is real, and for a high-growth consumer app, the bill at hundreds of thousands of users is a meaningful line item. Supabase Auth is essentially free up to a large user count and very cheap above it, because it is bundled with the database platform, which is why "are you already on Supabase" is such a decisive question.

The self-hosted libraries, Auth.js and Better Auth, cost nothing for the library itself. Your real costs are the database (which you have anyway) and an email provider for verification and magic-link emails, roughly a flat low monthly cost regardless of user count. The hidden cost is engineering time: building the missing pieces, handling the edge cases, maintaining it. For Auth.js that hidden cost is larger because there are more missing pieces. For Better Auth it is smaller because the modern features are built in.

The pattern: managed platforms trade money for engineering time and speed. Self-hosted libraries trade engineering time for money and control. There is no universally correct trade; there is a correct trade for your specific cost sensitivity and engineering capacity.

The decision logic we use

When we scope auth for a client SaaS, we walk this in order.

Are you already on Supabase? If yes, Supabase Auth is the default unless a specific requirement, particularly enterprise SAML SSO, rules it out. The RLS integration alone justifies it. Do not adopt the whole Supabase stack just for auth, but if you are already there, use it.

Do you need enterprise SSO soon? If you are B2B SaaS expecting enterprise customers who will mandate SAML SSO and SCIM provisioning, that requirement narrows the field fast. Clerk handles organization management and enterprise features as first-class. Auth0 (the long-standing enterprise standard, more than we covered above) is built for exactly this. Supabase Auth's enterprise SSO is limited. Better Auth and Auth.js can do it but you are building more. If enterprise SSO is on the near roadmap, weight that heavily.

Is speed-to-production the priority? If you need auth working this week and you value engineering time over cost, Clerk gets you there fastest, with the best pre-built components in the category. This is the right call for a lot of early-stage products that need to validate the idea, not the auth system.

Do you want to avoid a per-user bill and own the stack? If you are comfortable self-hosting and want modern features, 2FA, passkeys, organizations, RBAC, without a per-user vendor charge, Better Auth is the strong 2026 answer. Auth.js if your team specifically wants the largest ecosystem and is fine building the missing pieces.

Is auth your actual product? Only then does custom build enter the conversation, and even then, scrutinize hard.

For most new client SaaS projects in 2026, the realistic outcome is Supabase Auth (if already on Supabase), Clerk (if speed and enterprise features matter and the cost math works), or Better Auth (if owning the stack and avoiding the per-user bill matter more). Auth.js remains a fine choice for teams that want it. Custom build is rare and deliberate.

What AI coding tools default to, and why it matters

One 2026-specific wrinkle: if you are scaffolding with AI coding tools, the auth solution the AI generates on the first pass often becomes the one you ship. And the default is not a recommendation; it is whatever appeared most in the training data.

Tools that scaffold full-stack apps around a specific backend tend to wire in that backend's auth, so a Supabase-oriented scaffolder produces Supabase Auth, because the architecture assumes it. General code assistants lean toward Auth.js because it dominates open-source examples. Clerk rarely appears as a default generation because it needs an account and API keys before any code works, so you have to choose it deliberately.

The takeaway: do not let the AI's default make this decision for you. The default reflects training-data frequency, not your stack, your growth profile, or your enterprise requirements. Decide the auth approach first, then have the tool implement the one you chose.

A note on the broader build

Auth is one decision inside a larger SaaS architecture, and it should be made in the context of the others, the database, the framework, the hosting model, the multi-tenancy approach. We wrote about the early-stage version of this in our SaaS MVP post. The auth choice ripples: Supabase Auth implies the Supabase platform, Clerk implies a managed-services posture, Better Auth implies you are comfortable self-hosting infrastructure. Pick auth in isolation and you can end up fighting the rest of the stack.

FAQ

What is the single most common right answer in 2026?

There isn't one, which is the honest answer, but the most common outcomes we land on are Supabase Auth when the project is already on Supabase, and Clerk when speed and enterprise features matter and the cost projection is acceptable. Better Auth has become a genuine third common answer in a way it was not earlier.

Is Auth.js outdated now that Better Auth exists?

No. Auth.js is mature, has the largest ecosystem, and v5 modernized it. Better Auth's advantage is that the modern features (2FA, passkeys, organizations, RBAC) are built in rather than assembled. If your team specifically values the largest ecosystem and is fine building those pieces, Auth.js is still a reasonable choice.

How much does vendor lock-in actually matter?

It matters most for managed platforms that store user data on their infrastructure, like Clerk. Migrating means exporting users and reimplementing flows, which is non-trivial but not catastrophic. Self-hosted options (Auth.js, Better Auth) have far less lock-in because the user data is in your own database. Weigh it according to how likely you are to switch, which for most products is "not very, but not never."

Do I need passkeys in 2026?

Passkeys went mainstream and all the major options now support them, managed platforms natively, Better Auth built-in, Auth.js with additional work. They are increasingly expected rather than optional, especially for security-conscious B2B buyers. If your auth approach supports passkeys with little extra effort, turn them on.

When does a custom auth build actually make sense?

When authentication is genuinely your core product differentiator, you have a security team with real depth, you have requirements no platform meets, and you can tolerate a 12-month-plus timeline. That is a narrow intersection. For the overwhelming majority of SaaS products, custom auth is rebuilding a solved problem and taking on its security liability.

Can I switch auth providers later if I get it wrong?

Yes, but it is a real migration, not a config change, especially moving off a managed platform that holds your user data. The cost of switching is exactly why the initial decision deserves more than an afternoon. It is recoverable, but it is the kind of recoverable you would rather not need.

Where to go from here

If you are starting a SaaS build and want the auth decision made properly in the context of the whole architecture, get in touch. We scope auth alongside the database, framework, hosting, and multi-tenancy choices, because deciding it in isolation is how stacks end up fighting themselves. You can read more about our SaaS and web app development work, and if your build needs to connect auth or user data to other systems, our API and system integration service covers that side.

For the broader early-stage picture, our SaaS MVP guide covers how the auth decision fits the rest of the first build.