Migrating from Auth.js to Better Auth
Introduction
In this guide, we'll walk through the steps to migrate a project from Auth.js (formerly NextAuth.js) to Better Auth. Since these projects have different design philosophies, the migration requires careful planning and work. If your current setup is working well, there's no urgent need to migrate. We continue to handle security patches and critical issues for Auth.js.
However, if you're starting a new project or facing challenges with your current setup, we strongly recommend using Better Auth. Our roadmap includes features previously exclusive to Auth.js, and we hope this will unite the ecosystem more strongly without causing fragmentation.
Create Better Auth Instance
Before starting the migration process, set up Better Auth in your project. Follow the installation guide to get started.
For example, if you use the GitHub OAuth provider, here is a comparison of the auth.ts file.
import NextAuth from "next-auth"
import GitHub from "next-auth/providers/github"
export const { handlers, signIn, signOut, auth } = NextAuth({
providers: [GitHub],
})import { betterAuth } from "better-auth";
export const auth = betterAuth({
socialProviders: {
github: {
clientId: process.env.GITHUB_CLIENT_ID!,
clientSecret: process.env.GITHUB_CLIENT_SECRET!,
},
},
})Now Better Auth supports stateless session management without any database. If you were using a Database adapter in Auth.js, you can refer to the Database models below to check the differences with Better Auth's core schema.
Create Client Instance
This client instance includes a set of functions for interacting with the Better Auth server instance. For more information, see here.
import { createAuthClient } from "better-auth/react"
export const authClient = createAuthClient()Update the Route Handler
Rename the /app/api/auth/[...nextauth] folder to /app/api/auth/[...all] to avoid confusion. Then, update the route.ts file as follows:
import { handlers } from "@/lib/auth"
export const { GET, POST } = handlersimport { auth } from "@/lib/auth";
import { toNextJsHandler } from "better-auth/next-js";
export const { POST, GET } = toNextJsHandler(auth)Session Management
In this section, we'll look at how to manage sessions in Better Auth compared to Auth.js. For more information, see here.
Client-side
Sign In
Here are the differences between Auth.js and Better Auth for signing in users. For example, with the GitHub OAuth provider:
"use client"
import { signIn } from "next-auth/react"
signIn("github")"use client"
import { authClient } from "@/lib/auth-client";
const { data, error } = await authClient.signIn.social({
provider: "github",
})Sign Out
Here are the differences between Auth.js and Better Auth when signing out users.
"use client"
import { signOut } from "next-auth/react"
signOut()"use client"
import { authClient } from "@/lib/auth-client";
const { data, error } = await authClient.signOut()Get Session
Here are the differences between Auth.js and Better Auth for getting the current active session.
"use client"
import { useSession } from "next-auth/react"
const { data, status, update } = useSession()"use client"
import { authClient } from "@/lib/auth-client";
const { data, error, refetch, isPending, isRefetching } = authClient.useSession()Server-side
Sign In
Here are the differences between Auth.js and Better Auth for signing in users. For example, with the GitHub OAuth provider:
import { signIn } from "@/lib/auth"
await signIn("github")import { auth } from "@/lib/auth";
const { redirect, url } = await auth.api.signInSocial({
body: {
provider: "github",
},
})Sign Out
Here are the differences between Auth.js and Better Auth when signing out users.
import { signOut } from "@/lib/auth"
await signOut()import { auth } from "@/lib/auth";
import { headers } from "next/headers";
const { success } = await auth.api.signOut({
headers: await headers(),
})Get Session
Here are the differences between Auth.js and Better Auth for getting the current active session.
import { auth } from "@/lib/auth";
const session = await auth()import { auth } from "@/lib/auth";
import { headers } from "next/headers";
const session = await auth.api.getSession({
headers: await headers(),
})Protecting Resources
Proxy(Middleware) is not intended for slow data fetching. While Proxy can be helpful for optimistic checks such as permission-based redirects, it should not be used as a full session management or authorization solution. - Next.js docs
Auth.js offers approaches using Proxy (Middleware), but we recommend handling auth checks on each page or route rather than in a Proxy or Layout. Here is a basic example of protecting resources with Better Auth.
"use client";
import { authClient } from "@/lib/auth-client";
import { redirect } from "next/navigation";
const DashboardPage = () => {
const { data, error, isPending } = authClient.useSession();
if (isPending) {
return <div>Pending</div>;
}
if (!data || error) {
redirect("/sign-in");
}
return (
<div>
<h1>Welcome {data.user.name}</h1>
</div>
);
};
export default DashboardPage;import { auth } from "@/lib/auth";
import { headers } from "next/headers";
import { redirect } from "next/navigation";
const DashboardPage = async () => {
const session = await auth.api.getSession({
headers: await headers(),
});
if (!session) {
redirect("/sign-in");
}
return (
<div>
<h1>Welcome {session.user.name}</h1>
</div>
);
};
export default DashboardPage;Database models
Both Auth.js and Better Auth provide stateless (JWT) and database session strategies. If you were using the database session strategy in Auth.js and plan to continue using it in Better Auth, you will also need to migrate your database.
Just like Auth.js has database models, Better Auth also has a core schema. In this section, we'll compare the two and explore the differences between them.
User -> User
| Field Name | Type | Key | Description |
|---|---|---|---|
| id | string | Unique identifier for each user | |
| name | string | User's chosen display name | |
| string | User's email address for communication and login | ||
| emailVerified | Date | When the user's email was verified | |
| image | string | User's image url |
| Field Name | Type | Key | Description |
|---|---|---|---|
| id | string | Unique identifier for each user | |
| name | string | - | User's chosen display name |
| string | - | User's email address for communication and login | |
| emailVerified | boolean | - | Whether the user's email is verified |
| image | string | User's image url | |
| createdAt | Date | - | Timestamp of when the user account was created |
| updatedAt | Date | - | Timestamp of the last update to the user's information |
Session -> Session
| Field Name | Type | Key | Description |
|---|---|---|---|
| id | string | Unique identifier for each session | |
| userId | string | The ID of the user | |
| sessionToken | string | - | The unique session token |
| expires | Date | - | The time when the session expires |
| Field Name | Type | Key | Description |
|---|---|---|---|
| id | string | Unique identifier for each session | |
| userId | string | The ID of the user | |
| token | string | - | The unique session token |
| expiresAt | Date | - | The time when the session expires |
| ipAddress | string | The IP address of the device | |
| userAgent | string | The user agent information of the device | |
| createdAt | Date | - | Timestamp of when the session was created |
| updatedAt | Date | - | Timestamp of when the session was updated |
Account -> Account
| Field Name | Type | Key | Description |
|---|---|---|---|
| id | string | Unique identifier for each account | |
| userId | string | The ID of the user | |
| type | string | - | Type of the account (e.g. 'oauth', 'email', 'credentials') |
| provider | string | - | Provider identifier |
| providerAccountId | string | - | Account ID from the provider |
| refresh_token | string | The refresh token of the account. Returned by the provider | |
| access_token | string | The access token of the account. Returned by the provider | |
| expires_at | number | The time when the access token expires | |
| token_type | string | Type of the token | |
| scope | string | The scope of the account. Returned by the provider | |
| id_token | string | The ID token returned from the provider | |
| session_state | string | OAuth session state |
| Field Name | Type | Key | Description |
|---|---|---|---|
| id | string | Unique identifier for each account | |
| userId | string | The ID of the user | |
| accountId | string | - | The ID of the account as provided by the SSO or equal to userId for credential accounts |
| providerId | string | - | The ID of the provider |
| accessToken | string | The access token of the account. Returned by the provider | |
| refreshToken | string | The refresh token of the account. Returned by the provider | |
| accessTokenExpiresAt | Date | The time when the access token expires | |
| refreshTokenExpiresAt | Date | The time when the refresh token expires | |
| scope | string | The scope of the account. Returned by the provider | |
| idToken | string | The ID token returned from the provider | |
| password | string | The password of the account. Mainly used for email and password authentication | |
| createdAt | Date | - | Timestamp of when the account was created |
| updatedAt | Date | - | Timestamp of when the account was updated |
VerificationToken -> Verification
| Field Name | Type | Key | Description |
|---|---|---|---|
| identifier | string | Identifier for the verification request | |
| token | string | The verification token | |
| expires | Date | - | The time when the verification token expires |
| Field Name | Type | Key | Description |
|---|---|---|---|
| id | string | Unique identifier for each verification | |
| identifier | string | - | The identifier for the verification request |
| value | string | - | The value to be verified |
| expiresAt | Date | - | The time when the verification request expires |
| createdAt | Date | - | Timestamp of when the verification request was created |
| updatedAt | Date | - | Timestamp of when the verification request was updated |
Comparison
Table: User
name,email, andemailVerifiedare required in Better Auth, while optional in Auth.jsemailVerifieduses a boolean in Better Auth, while Auth.js uses a timestamp- Better Auth includes
createdAtandupdatedAttimestamps
Table: Session
- Better Auth uses
tokeninstead ofsessionToken - Better Auth uses
expiresAtinstead ofexpires - Better Auth includes
ipAddressanduserAgentfields - Better Auth includes
createdAtandupdatedAttimestamps
Table: Account
- Better Auth uses camelCase naming (e.g.
refreshTokenvsrefresh_token) - Better Auth includes
accountIdto distinguish between the account ID and internal ID - Better Auth uses
providerIdinstead ofprovider - Better Auth includes
accessTokenExpiresAtandrefreshTokenExpiresAtfor token management - Better Auth includes
passwordfield to support built-in credential authentication - Better Auth does not have a
typefield as it's determined by theproviderId - Better Auth removes
token_typeandsession_statefields - Better Auth includes
createdAtandupdatedAttimestamps
Table: VerificationToken -> Verification
- Better Auth uses
Verificationtable instead ofVerificationToken - Better Auth uses a single
idprimary key instead of composite primary key - Better Auth uses
valueinstead oftokento support various verification types - Better Auth uses
expiresAtinstead ofexpires - Better Auth includes
createdAtandupdatedAttimestamps
If you were using Auth.js v4, note that v5 does not introduce any breaking changes to the database schema. Optional fields like oauth_token_secret and oauth_token can be removed if you are not using them. Rarely used fields like refresh_token_expires_in can also be removed.
Customization
You may have extended the database models or implemented additional logic in Auth.js. Better Auth allows you to customize the core schema in a type-safe way. You can also define custom logic during the lifecycle of database operations. For more details, see Concepts - Database.
Wrapping Up
Now you're ready to migrate from Auth.js to Better Auth. For a complete implementation with multiple authentication methods, check out the Next.js Demo App. Better Auth offers greater flexibility and more features, so be sure to explore the documentation to unlock its full potential.
If you need help with migration, join our community or reach out to contact@better-auth.com.