Next.js Authentication Frameworks in 2025/2026: Auth.js v5, Clerk, Better Auth, and Lucia Compared for B2B SaaS

Short answer: For a new Next.js B2B SaaS in late 2026, the realistic choice is between Better Auth (self-hosted, open source, organizations and SSO as plugins) and Clerk (managed, fastest path to enterprise SSO, priced per retained user). Auth.js v5 still works and still gets security fixes, but it has been in maintenance mode under the Better Auth team since September 2025 and v5 never left beta. Lucia is no longer a library: it was deprecated in March 2025 and is now a guide for writing your own session code.

Authentication is the first architectural decision you make in a Next.js project and, statistically, the one you are most likely to regret. The library that felt like the obvious choice in year one starts showing friction in year two: when you need organization-scoped permissions, when an enterprise prospect asks about SAML SSO, or when you realize your session data lives in a country that just triggered a GDPR audit.

The Next.js authentication frameworks comparison looks very different from what it was two years ago, and it changed again during 2026. Auth.js handed its maintenance to the Better Auth team and stopped feature development. Lucia's author deprecated the npm package and turned the project into a learning resource. Better Auth grew into the default self-hosted option and was acquired by Vercel in July 2026, with the library staying MIT-licensed. Clerk kept expanding its B2B features and reworked its pricing around monthly retained users.

This article breaks down all four across the dimensions that matter for B2B SaaS: project status, multi-tenant architecture, RBAC and organization support, enterprise SSO, passkeys, GDPR data residency, how each fits Next.js 16, and the realistic migration path if you need to switch.

Where Each Library Stands in September 2026

	Status	Hosting	Organizations and RBAC	Enterprise SSO
Auth.js v5	Maintenance mode since September 2025 (security fixes only), v5 still published as beta	Self-hosted	Build it yourself	Build it yourself
Clerk	Actively developed, commercial	Managed	Built in, B2B add-on for larger orgs	SAML and OIDC connections, one included on paid plans
Better Auth	Actively developed, MIT, owned by Vercel since July 2026	Self-hosted	Organization plugin	SSO plugin (SAML, OIDC), SCIM plugin
Lucia	Deprecated March 2025, npm package no longer maintained	Your own code	Build it yourself	Build it yourself

The status column matters more than it did a year ago. A library in maintenance mode is not a security risk on day one, but every feature you need later is a feature you build yourself or migrate for.

Why Authentication Framework Choice Matters More in B2B Than B2C

Consumer applications can absorb auth mistakes. If your social login breaks, users reset their password and move on. B2B applications have no such tolerance. Enterprise customers need to provision and deprovision dozens of seats from their existing IdP. Your largest account will ask for audit logs. Your compliance team will ask where session tokens are stored and for how long. A junior hire who joins your team in month eighteen needs to understand the auth model without reading three blog posts.

The wrong auth choice does not reveal itself on day one. It reveals itself when a mid-market customer says "we need SSO" and you realize the library you chose treats SAML as a premium enterprise plugin you do not own the roadmap for.

Auth.js v5 (Formerly NextAuth)

Auth.js v5 is a ground-up rewrite of NextAuth.js, and it resolved most of the v4 complaints that made the library feel dated: a simpler, more TypeScript-idiomatic configuration, a single auth() function that works across Server Components, Route Handlers and middleware, and JWT sessions by default with database sessions via adapters.

The project's situation changed in September 2025, when the Auth.js maintainers announced that the Better Auth team would take over maintenance. Auth.js is now in maintenance mode: security patches and urgent fixes continue, new features do not. The Better Auth team recommends Better Auth for new projects, and has published a migration guide from NextAuth. On npm, the latest tag of next-auth still points to v4, and v5 is still published under the beta tag. Many production apps run the v5 beta without trouble, but some security and procurement reviews will flag a beta dependency, so be ready to explain it.

For a basic multi-tenant SaaS, Auth.js v5 still works well. You handle organization isolation yourself through the database adapter, which means full control but also full responsibility. RBAC is entirely on you. There is no built-in concept of organizations, roles, or permissions; you model those in your own schema and enforce them in your proxy, Server Actions and data access layer.

The GDPR picture is where Auth.js has always been strong for European companies: all session data lives in your own database, on your own infrastructure, in whatever region you choose. There are no third-party vendors in the session path unless you explicitly add them.

Best for: Existing projects that already run on Auth.js and have their RBAC and tenant model in place. Also still a reasonable fit for hybrid Next.js + Symfony architectures, where Auth.js handles the Next.js front-end session while the Symfony API validates tokens independently. If this combination is relevant to your setup, our custom development team can walk you through the wiring.

Watch out for: Starting a new project on it. Every capability you will need later (organizations, SAML, SCIM, passkeys beyond the basics) is now permanently your own work, and the adapter ecosystem will not get new investment.

Clerk

Clerk is the managed authentication platform that raised the quality bar for what "auth as a service" means. It ships with organization management, role and permission primitives, a polished component library, passkey support, and enterprise SSO over SAML and OIDC, all of it production-ready out of the box.

The developer experience is fast. Getting Clerk running in a Next.js project takes under an hour, and the built-in OrganizationSwitcher and UserProfile components handle the UI surface that most teams spend weeks building from scratch. For a B2B SaaS where organization and role management is core to the product, Clerk removes a significant amount of work.

Pricing is now based on monthly retained users (MRU) rather than monthly active users: a user counts once they come back at least a day after signing up, so one-time sign-ups are free. At the time of writing, Clerk's pricing page lists a free Hobby plan up to 50,000 MRU per app, Pro at $25 per month, Business at $300 per month, and custom Enterprise contracts. Basic organizations (up to 100 retained organizations with up to 20 members each) are included; a B2B Authentication add-on at $100 per month removes the member limits and adds verified domains and custom roles. Paid plans include one enterprise SSO connection per app, and additional connections are billed per connection. Check the current page before you model costs, because these numbers have moved more than once.

The trade-off is still data residency. Session tokens and user data pass through Clerk's infrastructure. For companies serving EU customers with strict GDPR requirements, or those under contracts that prohibit third-party sub-processors without explicit approval, Clerk introduces a conversation with your legal team. Check Clerk's current data residency options and DPA against your specific requirements before committing.

Best for: Teams that need enterprise SSO on a short timeline, startups where developer velocity is the primary constraint, and products where user management UI is a core feature rather than plumbing.

Watch out for: Long-term vendor dependency. Migrating away from Clerk later is possible but involves reworking every place you called Clerk's SDK. Price modeling matters: run the numbers for per-connection SSO fees and the B2B add-on at your projected three-year scale, not only the per-user rate. We compared the two most common options in more depth in Clerk vs Auth.js v5 in 2026.

Better Auth

Better Auth started as the TypeScript-first challenger and has become the default self-hosted option for new Next.js projects. Two events in the past year made that official in practice: taking over Auth.js maintenance in September 2025, and Vercel's acquisition of the company in July 2026. Vercel's announcement states that the library stays free and MIT-licensed, keeps its name, stays framework-agnostic, and continues to be led by the same team. That is worth tracking over the coming releases, but for now nothing in the licence or the self-hosting model has changed.

It was built with Drizzle and Prisma adapters as first-class citizens and fits the modern Next.js stack without adapter shims. The configuration object is strongly typed, auto-completion works across the entire setup, and the plugin system for extending functionality is coherent rather than patched together.

For B2B SaaS, the plugin list is what sets it apart from Auth.js. The organization plugin covers organizations, members, invitations and roles. The SSO plugin handles SAML and OIDC connections per organization, and a SCIM plugin handles directory provisioning. Passkeys are a plugin as well. Version 1.4 (late 2025) added stateless sessions without a database, which removed the last common reason to stay on Auth.js for JWT-only setups. None of this is as polished as Clerk's hosted UI, since you still build the screens, but the primitives are there and they live in your database.

Data residency is self-hosted, matching Auth.js in the GDPR picture: everything lives in your database, in your region.

Best for: New projects that want a self-hosted option with organizations, RBAC and enterprise SSO available without writing them from scratch. The obvious migration target for teams leaving Auth.js.

Watch out for: Plugin maturity varies. The core and the organization plugin are widely used; enterprise features like SAML and SCIM have fewer production deployments behind them, so test them against the IdPs your customers actually use (Entra ID and Okta at minimum) before you promise them in a sales call.

Lucia (Deprecated)

Lucia took a different philosophy from the start: it was not an authentication framework but a small library for session management that got out of your way on everything else. That philosophy won, in a way. In March 2025 its author deprecated the npm package and turned lucia-auth.com into a learning resource that shows how to implement sessions yourself, with a single-file replacement for the library that you copy into your project and own.

So "choosing Lucia" in 2026 means choosing to write your own session layer, with a well-documented reference implementation to start from. That is still the right call in a narrow set of cases: session management tied closely to a custom token format, multi-tenancy logic that does not fit any library's organization model, or a Next.js front end that authenticates against an existing backend API that already owns the auth logic.

The trade-off has not changed. "Minimal" means you build more. Social login providers, password reset flows, email verification, passkeys, rate limiting and SSO are all your responsibility, and so is every security fix.

Best for: Teams with specific requirements that no library handles cleanly, and a senior developer who understands session security well.

Watch out for: Projects still importing the lucia npm package. It no longer receives fixes. Plan the move to the copied reference code or to Better Auth before the next security review asks about it.

What Next.js 16 Changes for Authentication

Two framework changes affect every option above.

middleware.ts became proxy.ts. Next.js 16 renamed middleware to proxy and runs it on the Node.js runtime. The old middleware.ts still works for Edge runtime use cases but is deprecated. For auth this is mostly good news: the Edge runtime restrictions that made database session checks awkward in middleware no longer apply in proxy.ts. Keep the proxy check light anyway (a redirect for signed-out users), and do the real authorization check next to the data, in Server Actions and your data access layer. A proxy check alone is not an authorization boundary.

Cache Components change where you read the session. With cacheComponents enabled, reading cookies() or headers() at the top of a page makes that route block on request data. The pattern that works is to read the session inside a component wrapped in <Suspense>, so the rest of the page can prerender, and to keep request data out of 'use cache' scopes entirely. If you cache anything derived from the session, pass the user or tenant ID in explicitly so it becomes part of the cache key. We covered the caching side in our guide to Next.js caching and revalidation.

Decision Matrix for B2B SaaS

The right choice depends on where you are in your product journey and what your enterprise customer requirements look like.

If you are pre-Series A, moving fast, and your early customers are not asking about data residency yet, Clerk gives you the most product surface with the least engineering investment. Model the B2B add-on and SSO connection fees, not only the MRU price, and make sure the contract structure you give customers does not create lock-in problems later.

If you have EU customers, a dedicated engineering team, and GDPR requirements that make third-party sub-processors complicated, Better Auth is the default self-hosted choice for a new project. Auth.js v5 only makes sense if you already run it.

If you have custom session requirements or are integrating with an existing backend that already handles auth, write your own session layer using the Lucia guide as the reference.

If enterprise SSO is on your roadmap within the next six months, Clerk is still the fastest path. Better Auth's SSO plugin is the self-hosted alternative, with more testing on your side. Auth.js needs a separate SAML-to-OIDC bridge that you deploy and operate yourself.

For hybrid Next.js + Symfony stacks, a common architecture at Wolf-Tech, the Next.js session layer (Better Auth for new builds, Auth.js v5 for existing ones) issues tokens that the Symfony API validates independently via a shared JWT key or an introspection endpoint. This gives you full data residency, clean separation between front-end session management and API authorization, and a Symfony backend that remains testable and independently deployable. If your architecture looks like this, reach out at hello@wolf-tech.io. We have implemented this pattern multiple times and can help you avoid the edge cases that cost teams several weeks.

Migration Paths: What to Do If You Chose Wrong

Migrating between auth frameworks is painful but not impossible. The key variable is how deeply the auth library's session model is embedded in your application code.

From NextAuth v4 to Auth.js v5, the migration is relatively contained, and the official migration guide covers most scenarios. In 2026 it is worth asking whether to skip that step and go straight to Better Auth instead.

From Auth.js to Better Auth, the Better Auth docs include a dedicated migration guide. The data models are close enough that the guide maps them table by table, and the main work is replacing auth() calls and moving any custom JWT callbacks into Better Auth's session hooks. Plan a forced re-login on cutover unless you invest in session translation.

From the lucia package to your own code, the Lucia site documents the move to the single-file implementation. The data model stays the same, so this is mostly a code change.

From Auth.js, Lucia or Better Auth to Clerk, the main work is replacing session validation code with Clerk's SDK calls and migrating the user database into Clerk's user store. Clerk provides an import API, but mapping custom fields and organization structures is manual work.

From Clerk to a self-hosted solution, plan for several weeks on a mature codebase. Every place you called auth(), currentUser(), or the SignIn component needs to be replaced. The session data export is manageable; losing Clerk's org management API is the harder part.

The meta-lesson: abstract your auth calls behind a thin interface layer from day one. Even a simple getSession() wrapper that you control means you can swap the underlying implementation with a search-and-replace scope rather than a distributed refactor. It takes one afternoon at project setup, and 2025 and 2026 showed why it matters: two of the four libraries in this comparison changed status in eighteen months.

Building on a Solid Foundation

Authentication is not the most exciting part of building a SaaS product, but it is foundational in the most literal sense: everything you build sits on top of it. A poor choice at this layer creates drag that compounds across every feature, every enterprise sale, and every compliance conversation.

If you are evaluating Next.js authentication frameworks for a B2B product and want a second opinion from a team that has shipped this in production across multiple architectures, Wolf-Tech works with companies at exactly this stage. Whether you need a code audit to assess an existing implementation, architectural advice on the right framework for your stack, or a hands-on team to build it out, you can reach us at hello@wolf-tech.io or through wolf-tech.io.

The right framework is the one you will still be comfortable with in two years, under production load, with a compliance questionnaire in your inbox. Take the afternoon to make the call deliberately. It is worth it.