Yes, SvelteKit can run the library once known as NextAuth.js, but treating that as a 2026 launch misreads the situation. Auth.js, the framework-agnostic successor to NextAuth.js, shipped SvelteKit, SolidStart, Express, and Qwik bindings as part of its v5 line, and a migration guide dated 2026-04-27 already treats them as established. The larger recent shift is that Auth.js has been consolidated into Better Auth, and its own maintainers now steer new projects there.
What is Auth.js in 2026?
Auth.js is the renamed, generalized form of NextAuth.js, and in 2026 it is officially a Better Auth project. The Auth.js GitHub README states it plainly: “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).” The authjs.dev site carries the same message in its navigation, including a dedicated “Migrate to Better Auth” entry, and the Integrations page footer reads “Auth.js © Better Auth Inc. - 2026.”
The rebrand from NextAuth.js to Auth.js, which the migration guide dates to late 2024, reflected that the core was no longer Next.js-specific. The more recent change is governance: the project now sits under the Better Auth umbrella, and the docs openly funnel new users toward Better Auth as the default. For anyone arriving from a stale tutorial that says “install next-auth,” the practical starting point has moved.
That does not make Auth.js dead. The v5 line is still documented, still published under the @auth/* namespace, and still the migration target for existing NextAuth.js v4 apps. But a team starting greenfield in mid-2026 is being told, by the project’s own README, to look elsewhere first.
How does the framework-agnostic architecture work?
The mechanism that lets one library serve SvelteKit, Next.js, and Express is a split between a shared core and thin per-framework wrappers. Per the Integrations documentation, “Framework and database integrations are all based on the Auth.js Core library,” which the Getting Started docs describe as runtime-agnostic and built on standard Web APIs. The Core handles the protocol work, the OAuth and OIDC flows, session encoding, and CSRF tokens, while each framework package supplies only the request and response glue that its runtime expects.
The Integrations page is blunt about who touches Core directly: “In most cases, you will not interact with this package directly, as it is intended for library authors.” Application developers import a framework binding; the binding imports Core. That layering is why a provider implemented once in Core is, in principle, available to every framework, and it is also why binding maturity, not provider coverage, is where the seams show.
The docs frame the lineage plainly: Auth.js began as next-auth, a Next.js-specific library, and the core has since become framework-agnostic. That evolution is the whole basis for the title’s claim, and it is real. Because the Core is shared, the same provider list and database adapters are available to every binding in principle. Because each binding is a separate package with its own maturity curve, the experience of using them is not uniform.
A naming detail worth pinning down: v4 packages lived under @next-auth/*, while v5 lives under @auth/*. The one exception is next-auth itself, which kept its npm name under v5 even as the adapter packages moved namespace. The Getting Started docs confirm the version boundary: the documentation covers next-auth@5.0.0-beta and later under @auth/*, while v4 docs remain at the legacy next-auth.js.org site.
Which frameworks actually have Auth.js bindings?
The Integrations page distinguishes released integrations from planned ones, and flags the planned entries as work the maintainers actively want help on. It also lists community-created bindings outside the official line. That distinction matters for any “auth is now portable everywhere” headline.
The migration guide names the four non-Next.js bindings the Auth.js team has published: SvelteKit, SolidStart, Express, and Qwik. The Getting Started docs confirm the Next.js package itself is still on next-auth@5.0.0-beta, with v4 at the legacy next-auth.js.org site. The Integrations page does not exhibit a per-binding readiness grid, so any claim that a specific binding has crossed a “stable” line needs to be checked against the live page or the package’s own changelog.
The database adapter story is more settled. The migration guide confirms the adapter packages all moved namespace from @next-auth/* to @auth/* under v5, keeping the persistence layer on a single package line across frameworks. The framework glue layer does not enjoy the same uniformity.
What changes when you migrate from NextAuth.js v4 to v5?
For teams already on v4, the move to Auth.js v5 is an architectural reshuffle, not a version bump. According to the 2026 migration guide, three structural changes define it: configuration is split into an Edge-safe auth.config.ts (used by middleware) and a full auth.ts (holding the adapter and secrets), the getServerSession() pattern is replaced by a single auth() helper, and every provider and adapter ships as its own package under the @auth/* namespace.
The reason for the config split is the Edge runtime. Middleware runs in a constrained environment that cannot safely import database adapters or secret-heavy code, so v5 separates the small, Edge-safe config from the full server-side configuration. The legacy v4 docs at next-auth.js.org still show the old single-file pattern, the [...nextauth].js route handler, getServerSession, and useSession, which makes the v4-to-v5 gap visible by direct comparison.
For a non-Next.js team, the migration question looks different. You are not moving from v4 to v5 on the same framework; you are adopting a @auth/* binding that has no v4 predecessor, so there is no [...nextauth].js route to retire. The work is wiring the framework’s request and response objects into the Core, which is exactly what each binding tries to abstract.
Should you pick Auth.js, Better Auth, or Auth0 in 2026?
The honest answer in mid-2026 is that Auth.js is a maintenance and migration path, Better Auth is the recommended greenfield path, and Auth0 still occupies the managed-enterprise niche. The Auth.js README is the deciding text: new projects should start with Better Auth unless they need stateless, database-free sessions, the one feature gap the maintainers single out.
That exception matters. NextAuth.js built its reputation on JWT-based stateless sessions that required no database, which made it attractive for demos, internal tools, and serverless deploys where a session store is awkward. Better Auth is more database-oriented by default. If stateless sessions are a hard requirement, Auth.js v5 remains the pragmatic choice despite the consolidation. If they are not, starting on Auth.js means choosing against the grain of the project’s own recommendation.
Auth0 sits elsewhere on the axis. It is a hosted, proprietary service rather than a library, trading control and unit cost for not operating auth infrastructure yourself. The tradeoff has not really changed: use it when compliance, enterprise SSO breadth, or team size make self-hosted auth more expensive than the license.
The second-order effect the title is reaching for is real, if narrower than it sounds. When auth is a shared Core with swappable bindings, the cost of moving an app off Next.js onto SvelteKit or SolidStart stops being “rewrite your auth” and becomes “swap one binding.” That lowers the switching cost, but only for teams whose auth usage fits what the non-Next.js bindings currently support. A binding the Integrations page lists as planned or community-maintained is permission to prototype, not a contract.
With the project consolidated under Better Auth Inc., the strategic owner of Auth.js’s future is no longer the Next.js community it started in. Read the title’s claim literally and it holds: SvelteKit can use the old NextAuth.js lineage. Read the 2026 reality alongside it and the picture inverts. That lineage is being steered toward a successor, the non-Next.js bindings sit at varying maturity levels, and auth is no longer a reason to stay on Next.js, largely because auth is no longer a reason to stay on any particular framework.
Frequently Asked Questions
What environment variable rename does the Auth.js v4-to-v5 migration require?
The migration requires renaming NEXTAUTH_SECRET to AUTH_SECRET, since the library is no longer Next.js-scoped. The change reaches beyond application code into CI pipelines, secrets managers, and any deployment configuration that references the old variable name. Teams running mixed v4 and v5 services during transition need to publish the secret under both names until the rollout completes.
Which OAuth providers from NextAuth.js v4 should teams re-verify before following the Better Auth migration?
The legacy v4 homepage documents Google, Facebook, Auth0, and Apple among its OAuth providers, but the consolidation docs do not publish a provider-parity grid between Auth.js and Better Auth. Teams with enterprise SSO requirements or less-common providers should confirm coverage on the Better Auth side before committing to the migration path the README recommends.
What does Vercel’s acquisition of NuxtLabs signal for framework-agnostic auth?
Vercel acquired NuxtLabs in July 2025, bringing the Nuxt framework’s creators in-house as part of a platform strategy that broadens beyond Next.js. That move lines up with auth libraries decoupling from single frameworks, since a multi-framework platform has little incentive to keep auth tied to one runtime. The Better Auth consolidation sits inside the same trend, making framework portability a baseline expectation rather than a differentiator.
What happens to existing NextAuth.js v4 apps that stay on v4?
Nothing forces them to migrate. The v4 documentation remains live at next-auth.js.org, and packages under the @next-auth/* namespace continue to function for installed apps. The consolidation shifts the recommended starting point for new projects and the long-term governance of the v5 line, but it does not deprecate existing v4 deployments.
