Authentication for web apps in 2026

Authentication used to be the hard part of building a web app. You'd spend two weeks on password hashing, session management, email verification, password reset, and rate limiting before you wrote a single feature. Then six months later you'd realise you missed a CSRF case and got bitten.

That's not the world we're in anymore. For most projects, the question isn't "how do I build auth?" It's "which managed service do I use?"

This post is about that choice. The three options that matter in 2026, what each does well, what each costs, and the dimension most teams underweight: operations.

The three real options

For a Next.js web app, the realistic choices:

1. Clerk — a fully managed auth-as-a-service. Drop-in UI components, hosted user database, OAuth providers preconfigured, MFA built in.
2. NextAuth (Auth.js) — open-source, self-hosted, library-style. You bring the database. They handle the protocol work.
3. Roll your own — custom code, custom database tables, custom flows. Modern libraries (Lucia, Better Auth) make this less painful than it used to be.

There are others (Auth0, Supabase Auth, Stytch, Firebase Auth, AWS Cognito). Each has a niche. Auth0 if you're enterprise. Supabase Auth if you're already on Supabase. Stytch if you want passwordless-first. Firebase Auth if you're in the Google ecosystem. We rarely reach for them in our work, so this post focuses on the three we actually pick between.

Clerk: when it's right

Clerk gives you a complete auth system in about an hour. UI components for sign-in, sign-up, user profile, organisation management. OAuth providers (Google, GitHub, Microsoft, Apple) work out of the box. MFA, password reset, email verification all included. Webhooks for user lifecycle events.

The trade is:

• You're paying per monthly active user. Free up to 10,000 MAU, then $25/month plus usage from there.
• The user data lives in Clerk's infrastructure. You have copies in your database (synced via webhook) but Clerk is the source of truth.
• The UI components are theirs. Customisable, but you don't own the markup.

Clerk is right when:

• You want to launch fast and not think about auth past week one.
• Your business model allows the per-MAU cost (B2B SaaS with paying customers usually does; consumer apps with free tiers usually don't).
• You're comfortable with a third party holding your user data.
• You don't have specific UI requirements that Clerk's components can't accommodate.

We pick Clerk for B2B SaaS projects where the founder wants to ship features instead of building auth. The total cost over the first year is usually less than what we'd charge to build equivalent auth from scratch.

NextAuth: when it's right

NextAuth (rebranded as Auth.js but most people still call it NextAuth) is a library. You install it, configure providers, connect a database adapter, and you have auth. The user data lives in your database. The session management is handled. The OAuth dance is done for you.

The trade:

• Free. No usage costs. No vendor lock-in.
• The defaults are reasonable but not magical. You'll need to configure things Clerk does for free (account linking, MFA, granular session control).
• The UI is yours. NextAuth gives you the API, you build the sign-in page.
• The library has changed shape across versions. Migrations between major versions have stung us.

NextAuth is right when:

• Cost matters and your MAU count would push Clerk over $200/month.
• You need to keep user data in your own database (compliance, data sovereignty, or just preference).
• Your UI requirements don't fit Clerk's components and you'd rather build than fight.
• You're OK reading the docs carefully and configuring it deliberately.

We pick NextAuth for projects where the founder is technical, the user data sensitivity is medium-high, or where Clerk's MAU pricing would dominate the budget.

Roll your own: when it's right

In 2026, "roll your own" doesn't mean writing password hashing from scratch. It means using a low-level library (Lucia or Better Auth) and composing the parts yourself. The hashing, session management, and OAuth are still libraries; you just don't outsource the overall flow.

The trade:

• Maximum control. The auth shape matches your app exactly.
• Maximum responsibility. Every edge case is yours. CSRF, session fixation, account takeover, race conditions on parallel sign-ins.
• The fastest sign-in UX, because nothing has to round-trip to a vendor or middleware.

Roll-your-own is right when:

• You have a specific auth flow that doesn't fit either library well. (e.g., magic-link with custom domain verification, multi-step auth tied to your product onboarding.)
• The team has shipped auth before and knows the edge cases.
• The product is small enough that the auth surface is bounded.

We pick this rarely. The cases that justify it usually have specific compliance or workflow constraints. For most projects, the time saved with Clerk or NextAuth is worth more than the control gained by rolling your own.

The operations dimension

The decision factor most teams underweight: what happens at 3am when auth breaks?

With Clerk, you file a support ticket and someone on their team fixes it. You read their status page. You wait. This is fine for most B2B apps and unbearable for any product that markets itself on uptime.

With NextAuth, you debug it yourself. The library is well-tested, but the interactions with your database, your OAuth provider, and your deployment platform are yours to figure out. The MTTR depends on your team's familiarity with the library and the stack.

With roll-your-own, you debug it yourself, but at least you know the code. Sometimes that's faster than untangling a library's internals. Often it's not, because the bug is in the part you've never had to look at since you wrote it.

For a lean team that's not 24/7 ops, Clerk's "someone else fixes it" is a real value. For a larger team with on-call rotation, NextAuth's "we own the code" is a real value. For everyone else, the answer is usually whichever you can debug fastest, which is whichever you've shipped before.

A decision matrix

We use a simplified decision matrix:

| Situation | Pick |
| Solo founder, B2B SaaS, want to ship | Clerk |
| Lean team, technical, cost-sensitive | NextAuth |
| Mid-size team, data sovereignty matters | NextAuth |
| Enterprise client, compliance-heavy | Auth0 or NextAuth on dedicated infra |
| Consumer app, high free-tier MAU | NextAuth (Clerk's pricing breaks) |
| Custom flow that fights both libraries | Roll your own |
| You've never shipped auth before | Clerk (the safety net matters) |

This isn't comprehensive. It's where we start, then adjust based on the specific project.

The trap: choosing wrong and migrating later

Auth migrations are painful. Not impossible, but painful in the way that "we'll fix it later" really means "we'll live with it for two years."

The user table is referenced by everything. The session model is intertwined with every protected route. The OAuth provider tokens (for "sign in with Google" type flows) are stored in formats specific to whatever library you used.

To migrate from Clerk to NextAuth, you'd need to:

• Export the user list.
• Map Clerk's user IDs to NextAuth's expected IDs (or change every reference in your database).
• Re-implement every UI that used Clerk's components.
• Re-authenticate every active user. Their existing Clerk session becomes invalid.

The last point is the killer. Forced re-authentication means thousands of users hitting your sign-in screen on the same day. Many will think the service is broken. Some will churn.

The advice: pick once, deliberately, with a year-out view of the project. Migrating in year one is expensive. Migrating in year three is a re-platform.

The boring recommendation

For most B2B SaaS projects we ship: Clerk in year one, with a clear eye on the MAU cost.

For most projects with cost or compliance pressure: NextAuth from day one.

Roll-your-own gets reserved for projects where neither fits, which is rare.

The library war over auth is mostly over. The choices are good. The decision is operational more than technical.

If you're building a web app and want a sane auth choice from the start, see how we work on web apps. We'll match the auth choice to the project, not the project to the auth choice.