Clerk vs NextAuth vs Supabase Auth — which one to pick in 2026
Three solid auth options, three different shapes. Clerk is the polished hosted product. NextAuth (now Auth.js) is the open-source DIY. Supabase Auth is the integrated default if you're on Supabase. Here is the honest comparison with the bugs each one ships at high frequency.
Three good auth options for Next.js apps in 2026: Clerk, NextAuth (rebranded Auth.js), and Supabase Auth. Each is a real choice with real tradeoffs.
This is the honest comparison — what each is best at, what each gets wrong when AI tools wire it up, and which one is right for your specific situation.
TL;DR
- Clerk: the polished hosted auth product. Best DX. Most expensive past free tier. Rich feature set (organizations, SAML, MFA, social providers).
- NextAuth (Auth.js): the open-source DIY option. Free forever. You host. Most flexibility. Steepest manual configuration.
- Supabase Auth: integrated with Supabase Postgres + RLS. Free with Supabase. Right answer if your data layer is Supabase. Less feature depth than Clerk.
If you're already on Supabase: Supabase Auth. If you want the most polished hosted experience: Clerk. If you want full control + no vendor lock-in: NextAuth.
Clerk — the polished hosted product
Best for: Apps that need rich auth features (organizations, SAML, MFA enforcement, social providers) without the engineering effort to build them.
The wins:
- Best UI components. Drop-in
<SignIn />,<UserButton />,<OrganizationSwitcher />components that look polished out of the box. - Strong organizations / multi-tenancy story. If your app has team accounts, Clerk's org primitives are genuinely useful.
- MFA is one toggle in the dashboard. SAML SSO is one toggle (in the paid tier).
- Long list of social providers (Google, GitHub, Apple, Facebook, Microsoft, Discord, Twitch, dozens more).
- Webhook events you can react to (user.created, session.created, organization.member.added).
- Generous free tier: 10K MAU.
The gotchas:
- Pricing scales fast past 10K MAU: $25/mo + $0.02/MAU. At 100K MAU that's $25 + $1,800 = ~$1,825/mo. Real money for a SaaS at that scale.
- Vendor lock-in is moderate. Migrating off Clerk is a real engineering project — your sessions, your social-provider relationships, your MFA enrollments are all in Clerk's database.
- Some Next.js patterns require Clerk-specific helpers (
auth(),<ClerkProvider>). Different from "I just check a JWT" vibes. - Webhook security — the
svix-signatureheader verification is critical, AI-generated Clerk webhook handlers sometimes skip it.
The security shape: Clerk handles the auth-server hardening (token issuance, session management, rate limiting on auth endpoints) better than most teams would build themselves. The bug surface is on YOUR side: webhook signature verification, ensuring auth() calls happen before privileged operations, and not putting Clerk's secret key in client code.
NextAuth (Auth.js) — the open-source DIY
Best for: Teams that want full control, no vendor lock-in, free.
The wins:
- Free. No usage caps. Self-hosted on whatever you deploy on.
- 80+ providers supported via the providers list. Anything OAuth-shaped works.
- Battle-tested. NextAuth has been around since 2019; the patterns are well-known and the documentation is mature.
- Open-source. You can read the auth-handler code to understand exactly what's happening.
The gotchas:
- More configuration. NextAuth requires you to wire up your own database adapter (Drizzle, Prisma, raw SQL, etc.), session strategy, callbacks for custom claims, and CSRF protection.
- The defaults are reasonable but not perfect. You should review every callback and option for your specific use case.
- Less polished UI components. Most NextAuth users build their own sign-in pages on top of
signIn()/signOut()helpers. - v5 (renamed Auth.js) has different APIs than v4 (NextAuth) — migration guides exist; AI-generated code sometimes mixes versions.
- The session callback is where AI tools ship bugs — code that includes user roles or org info from request data instead of from the verified database state.
The security shape: NextAuth's defaults are solid; the bugs are in the callbacks and database adapter. Common AI-generated mistakes: session-claim that doesn't re-fetch the user (stale role data), callback that trusts unverified provider data (Google "name" field is user-controlled), CSRF disabled "for testing" and never re-enabled.
Supabase Auth — the integrated default
Best for: Apps already on Supabase. The integration with RLS is the reason to pick it.
The wins:
- Free with your Supabase project. No additional MAU pricing.
- JWT integration with Supabase Postgres + RLS is seamless. Your RLS policies use
auth.uid()from the JWT claims directly. - Solid feature set: email/password, magic links, OAuth (Google / GitHub / Apple / many more), phone-OTP, anonymous auth, MFA via TOTP, SAML (paid plans).
- The Auth Hooks system (Custom Access Token Hook, MFA Verification Hook, Send Email Hook) lets you extend the auth flow with your own logic.
- Open-source via the GoTrue server. You can self-host the auth service if you self-host Supabase.
The gotchas:
- Less feature-deep than Clerk. No native organizations primitive — you build multi-tenancy yourself in Postgres.
- Less polished UI components than Clerk. Auth UI is via the
@supabase/auth-ui-reactlibrary which is functional but not as flexible as Clerk's components. - Tightly coupled with Supabase. If you ever want to migrate off Supabase, you migrate auth too — and your RLS policies were built around
auth.uid(). - The
getSession()vsgetUser()confusion is a real bug source —getSession()doesn't verify against the auth server,getUser()does. AI-generated code sometimes uses the wrong one.
The security shape: Supabase Auth is the auth half; RLS policies are the authorization half. Bugs concentrate in the policies (RLS off on a table, missing tenant scoping, USING-without-WITH-CHECK) rather than the auth service itself. Service-role key leaks bypass everything.
The matrix
| | Clerk | NextAuth | Supabase Auth | |---|---|---|---| | Hosted vs DIY | Hosted | DIY (self-host) | Hosted (with Supabase) | | Free tier | 10K MAU | Unlimited (you host) | Included with Supabase | | Pricing past free | $25/mo + $0.02/MAU | $0 (your hosting cost) | Included up to Supabase tier | | UI components | Best | Build your own | Functional | | Organizations / multi-tenant | Native primitive | DIY | DIY | | SAML | Yes (paid) | Yes (with config) | Yes (paid) | | Social providers | 30+ | 80+ | 20+ | | RLS integration | Manual | Manual | Native | | Lock-in | Moderate | Low | Moderate (with Supabase) | | Best for | Polish + features | Control + free | Supabase apps |
Cost example — 50K MAU SaaS
For a SaaS with 50K monthly active users:
- Clerk Pro: $25 + 50K × $0.02 = $1,025/month
- NextAuth: $0 (your hosting bill goes up by ~$10-20 to handle the auth-handler invocations)
- Supabase Auth: $0 (included with Supabase Pro at $25/mo, which you're paying anyway)
The 100x cost difference matters at scale. Most solo founders don't hit 50K MAU; for those that do, the Clerk premium is hard to justify unless the feature breadth (orgs, SAML, MFA) is doing real work.
Which one your AI coding tool would generate
Cursor / Lovable / Bolt default behaviors in 2026: - "Add auth to my Next.js + Supabase app" → almost always Supabase Auth - "Add auth with social providers + organizations" → often Clerk - "Add custom auth I can fully control" → NextAuth
The AI-tool defaults reflect the natural fit for each scenario.
What changes after you pick
All three options get the basics right. The bugs ship in the application code on top — auth checks missing on Server Actions, ownership checks missing on API routes, RLS misconfigurations (with Supabase Auth), webhook signature bugs (with Clerk).
Securie's broken-auth specialist (Day-1 production-validated) catches these bugs structurally. Sandbox-replays cross-user attacks against your routes; only ships findings when the attack succeeds. Works with all three auth options; integrates via the GitHub App.
My actual recommendation
If you're starting today on Supabase: Supabase Auth. The RLS integration is worth the slightly-thinner feature set.
If you have $100/mo of free budget and you want the most polished experience: Clerk. Stay below the 10K MAU free tier as long as possible.
If you specifically want no vendor lock-in or you're shipping at a scale where Clerk's pricing matters: NextAuth. Plan for more configuration work.
Related
Related posts
Supabase and Firebase are the two backend defaults for AI-built apps. Here is the honest comparison — what each is best at, where each one's bugs hurt most, and which one to pick for your specific stack.
Most auth tutorials show you how to add a login button. This is the guide that shows you how to add auth that actually works — what to wire up, what AI tools get wrong, and the bugs you ship if you copy-paste the first Stack Overflow answer.
From a growing sample of publicly-reachable Supabase projects we've audited, the same seven mistakes come up every time: RLS off on at least one table, service-role key in the client, missing tenant scoping, default-allow policies, no policies on storage buckets, exposed JWT secret, and over-broad anon-role grants. Fixes for each.
Moltbook leaked 1.5 million API keys, 35,000 emails, and 4,060 private messages in 72 hours. Wiz's disclosure showed the root cause: a single Supabase table without row-level security. Here is the timeline, the exact bug, and the ten-minute hardening walkthrough for your own app.