Migrating from Auth.js to Better Auth

A step-by-step guide to transitioning 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.

auth-client.ts
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 } = handlers
import { 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.

app/dashboard/page.tsx
"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;
app/dashboard/page.tsx
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

Table
Field
Type
Key
Description
id
string
pk
Unique identifier for each user
name
string
?
User's chosen display name
email
string
?
User's email address for communication and login
emailVerified
Date
?
When the user's email was verified
image
string
?
User's image url
Table
Field
Type
Key
Description
id
string
pk
Unique identifier for each user
name
string
—
User's chosen display name
email
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

Table
Field
Type
Key
Description
id
string
pk
Unique identifier for each session
userId
string
fk
The ID of the user
sessionToken
string
—
The unique session token
expires
Date
—
The time when the session expires
Table
Field
Type
Key
Description
id
string
pk
Unique identifier for each session
userId
string
fk
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

Table
Field
Type
Key
Description
id
string
pk
Unique identifier for each account
userId
string
fk
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
Table
Field
Type
Key
Description
id
string
pk
Unique identifier for each account
userId
string
fk
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

Table
Field
Type
Key
Description
identifier
string
pk
Identifier for the verification request
token
string
pk
The verification token
expires
Date
—
The time when the verification token expires
Table
Field
Type
Key
Description
id
string
pk
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, and emailVerified are required in Better Auth, while optional in Auth.js
  • emailVerified uses a boolean in Better Auth, while Auth.js uses a timestamp
  • Better Auth includes createdAt and updatedAt timestamps

Table: Session

  • Better Auth uses token instead of sessionToken
  • Better Auth uses expiresAt instead of expires
  • Better Auth includes ipAddress and userAgent fields
  • Better Auth includes createdAt and updatedAt timestamps

Table: Account

  • Better Auth uses camelCase naming (e.g. refreshToken vs refresh_token)
  • Better Auth includes accountId to distinguish between the account ID and internal ID
  • Better Auth uses providerId instead of provider
  • Better Auth includes accessTokenExpiresAt and refreshTokenExpiresAt for token management
  • Better Auth includes password field to support built-in credential authentication
  • Better Auth does not have a type field as it's determined by the providerId
  • Better Auth removes token_type and session_state fields
  • Better Auth includes createdAt and updatedAt timestamps

Table: VerificationToken -> Verification

  • Better Auth uses Verification table instead of VerificationToken
  • Better Auth uses a single id primary key instead of composite primary key
  • Better Auth uses value instead of token to support various verification types
  • Better Auth uses expiresAt instead of expires
  • Better Auth includes createdAt and updatedAt timestamps

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.