# NextAuth.js / Auth.js: what the repository actually ships in 2026

> The ISC-licensed authentication library for Next.js and other JS frameworks is now part of Better Auth, and its own README tells new projects to start elsewhere. Here is what that means for anyone deciding whether to adopt it today.

**nextauthjs/next-auth** — Authentication for the Web.

- Repository: https://github.com/nextauthjs/next-auth
- Website: https://authjs.dev
- Stars: 28,373 · Forks: 4,039
- Language: TypeScript
- License: ISC
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/nextauthjs-next-auth

## The problem NextAuth.js solves, and who it is actually for

Rolling your own OAuth callback handler is a week of work that ends with a CSRF bug. NextAuth.js exists to remove that week. The README describes Auth.js as "a set of open-source packages that are built on standard Web APIs for authentication in modern applications with any framework on any platform in any JS runtime." The target reader is a JavaScript or TypeScript developer who needs sign-in working across Next.js, SvelteKit, Express, Qwik, Nuxt or SolidStart without writing provider-specific token exchange code.

The scope is deliberately narrow. It handles the sign-in flow, session representation and cookie policy. It does not give you a user management UI, an admin panel, role editing or password reset emails. Those are yours to build on top, or to source from a hosted identity provider. If you need a complete identity product with a dashboard, this is the wrong layer of the stack.

The README carries a notice that changes the adoption calculus: "Auth js is now part of Better Auth. We recommend new projects to start with Better Auth unless there are some very specific feature gaps (most notably stateless session management without a database)." That sentence is the single most important thing on the page. It is not a deprecation notice, but it is an explicit steer away from greenfield use.

## How the sign-in flow works: providers, CSRF tokens and encrypted JWT sessions

The architecture separates three concerns. Providers describe how to talk to an identity source. Adapters describe how to persist users, accounts and sessions. The core package wires them together and exposes HTTP routes.

On the provider side, the README states the library "is designed to work with any OAuth service, it supports 2.0+, OIDC" and ships "built-in support for many popular sign-in services." Providers live under packages/core/src/providers in the repository, so the list is inspectable rather than a marketing claim. Email and passwordless sign-in, plus passkeys and WebAuthn, are listed as supported mechanisms.

Security behaviour is where the design shows. POST routes for sign in and sign out carry CSRF tokens. The default cookie policy "aims for the most restrictive policy appropriate for each cookie." When JSON Web Tokens are used for sessions, the README says they "are encrypted by default (JWE) with A256CBC-HS512." That is encryption, not just signing, which matters because a signed-but-readable JWT leaks whatever you put in it to anyone holding the cookie.

The database is optional. The README frames this as "Bring Your Database - or none! - stateless authentication with any backend (Active Directory, LDAP, etc.)." With no adapter, session state lives entirely in the encrypted cookie and the server keeps nothing. With an adapter, sessions become rows you can revoke. The README also mentions "tab/window syncing and session polling to support short-lived sessions," which is the mechanism that keeps multiple open tabs from disagreeing about whether you are still signed in.

Advanced configuration lets you replace the routines that decide who may sign in, that encode and decode JWTs, and that set cookie security policy and session properties. That is the escape hatch when the defaults do not match your compliance requirements.

## Setting up NextAuth.js in a Next.js App Router project

The README does not contain install steps; it points to https://authjs.dev for documentation. The package name below is the one that appears in the repository's release list, next-auth@4.24.15, published on 2026-07-20. The repository files given here do not include a route handler example or an environment variable name, so the snippet after the install line shows the package's own name only, and you should confirm the exact file layout and configuration keys against the current docs for your version before writing them.

The published package for Next.js is next-auth:

```bash
npm install next-auth
```

After installing, the README's security section tells you what to expect on the wire: the sign-in and sign-out POST routes are protected by CSRF tokens, and the session cookie is set under the restrictive default policy. If you configured no adapter, the session is the encrypted JWE cookie and nothing is written to a database. If you configured one, the same flow writes user, account and session records through that adapter.

What you should see: a working sign-in route, a session readable on the server, and a cookie whose attributes match the defaults rather than a wildcard domain. The README does not document a generator command for the encryption secret, so source that value with a tool you trust rather than copying one from a tutorial.

## Where NextAuth.js stops being the right tool

The README's own recommendation is the first limitation. New projects are told to start with Better Auth unless they need stateless session management without a database. That is an unusually direct statement from a project about itself, and it means anyone choosing NextAuth.js today is choosing it for a specific reason, not by default.

The second limitation is the split between versions. The release list shows next-auth@4.24.15 as the latest stable on the next-auth package line, while the repository's package.json test script and the README's own TODO comment reference a v5 that the README still describes as unreleased ("Should count @auth/core when NextAuth.js v5 is released as stable"). The related searches people run include next auth v5, next auth 5 and next auth beta, which suggests real confusion in the wild about which line to install. If you follow a v5 tutorial while installing the stable v4 package, the import paths and configuration shape will not match.

Third, adapters are not equally exercised. The root test script excludes a long list from the default run: dynamo, edgedb, hasura, mikro, dgraph, xata and typeorm all appear as negative filters. That does not mean those adapters are broken, but it does mean the default CI path does not cover them, so your own testing carries more weight if you pick one.

Fourth, stateless sessions have a real cost. With no adapter, you cannot revoke a session server-side; you can only wait for the cookie to expire or rotate the secret, which invalidates every session at once. If your threat model requires per-session revocation, you need an adapter, and the "no database" advantage disappears.

## NextAuth.js versus Better Auth: the actual difference

The comparison is not hypothetical, because the README makes it for you. Better Auth is the project Auth.js joined, and it is the one the README recommends for new work.

The concrete difference the README names is stateless session management without a database. NextAuth.js can run with no persistence layer at all: the session is an encrypted JWE cookie, the server stores nothing, and you can deploy to a serverless runtime with no database connection. That is a genuine architectural property, not a feature checkbox, and it is the case the README carves out as still valid for Auth.js.

Better Auth is positioned as the default choice for everything else, which implies it assumes a persistence layer for its full feature set. If you are already running Postgres or MySQL, that assumption costs you nothing and you get the project that is receiving new development.

The practical decision rule: if your deployment cannot hold a database connection, or you specifically want sessions that exist only as encrypted client-side state, NextAuth.js remains the fit. If you have a database and want the maintained path, the README's recommendation points the other way. What the README does not do is enumerate the other feature gaps it alludes to, so if you are evaluating on a specific capability, check the docs rather than assuming.

## Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-07-22. Releases are still shipping: next-auth@4.24.15 on 2026-07-20, alongside adapter releases @auth/xata-adapter@1.11.3 and @auth/upstash-redis-adapter@2.11.3 on the same day. So the v4 line is receiving fixes, even as new-project guidance points elsewhere.

The licence is ISC, a permissive licence that appears in the repository root as LICENSE. It permits use, modification and redistribution with the licence text retained. That is a permissive arrangement comparable in effect to MIT, and it does not impose copyleft obligations on your application. This is a description of the licence identifier, not legal advice; if your organisation has specific requirements, have counsel read the LICENSE file.

The upgrade cost is the part worth budgeting. The repository is a pnpm and turbo monorepo, with packages/, apps/ and docs/ as the top-level working directories and turbo.json driving the task graph. That structure is for contributors, not consumers. For you, the cost is the v4 to v5 transition: the README's TODO comment about @auth/core being counted once v5 is stable is a marker that the package boundaries themselves shift between lines. Any upgrade should be planned as a configuration migration, not a version bump, and the search interest in next auth v5 and next auth beta suggests many teams are already mid-migration.

## Conclusion

Adopt NextAuth.js if you already run it, or if you need stateless session management without a database, which the README names as the specific feature gap where it still beats Better Auth. Do not start a new project on it otherwise: the README itself recommends Better Auth for new work. Before committing, verify which major version your framework integration targets, confirm whether your chosen adapter is among the ones excluded from the default test script, and decide whether you are storing sessions in a database or in an encrypted cookie, because that choice drives the rest of your configuration.

## FAQ

### What does NextAuth.js do?

It handles authentication for JavaScript applications: OAuth 2.0 and OIDC sign-in, email and passwordless flows, and passkeys, plus the session cookie and CSRF protection around those routes. The README describes it as a set of open-source packages built on standard Web APIs that work with any framework on any JS runtime.

### Is NextAuth.js deprecated?

The README does not use that word. It states that Auth.js is now part of Better Auth and recommends new projects start with Better Auth unless they need stateless session management without a database. The repository is not archived and released next-auth@4.24.15 on 2026-07-20.

### What are the differences between Better Auth and NextAuth.js?

The README names one specific gap where NextAuth.js still wins: stateless session management without a database, where the encrypted JWE cookie holds all session state and the server persists nothing. For everything else it directs new projects to Better Auth.

### How do I install NextAuth.js?

The README does not include install instructions and points to https://authjs.dev for documentation. The published package is next-auth, which is the name that appears in the release list.

### What is the NextAuth.js secret?

It is the value the library uses to encrypt session tokens. The README states that when JSON Web Tokens are used, they are encrypted by default with JWE using A256CBC-HS512, so the secret is what protects the contents of that cookie.

### What is the NextAuth.js CSRF token for?

The README states that Cross-Site Request Forgery tokens are used on POST routes, specifically sign in and sign out. They prevent another site from triggering those state-changing requests on a signed-in user's behalf.

## Sources

- [License: ISC](https://github.com/nextauthjs/next-auth/blob/main/LICENSE)
- [nextauthjs/next-auth on GitHub](https://github.com/nextauthjs/next-auth)
- [Project website](https://authjs.dev)
- [README](https://github.com/nextauthjs/next-auth/blob/main/README.md)
- [Releases](https://github.com/nextauthjs/next-auth/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nextauthjs-next-auth