Add authentication to your Auth.js (Next Auth) application

This guide will show you how to integrate Logto into your Next.js application with Auth.js, previously known as Next Auth.

tip:

In this guide, we assume you have set up Next Auth in your Next.js project. If you haven't, check out the Next Auth documentation to get started.

Prerequisites

A Logto Cloud account or a self-hosted Logto.
A Logto traditional application created.
A Next.js project with Auth.js, check out the Auth.js documentation.

Installation

Install Auth.js via your favorite package manager:

npm
pnpm
yarn

npm i next-auth@beta

pnpm add next-auth@beta

yarn add next-auth@beta

See Auth.js documentation for more details.

Integration

Set up Auth.js provider

tip:

You can find and copy "App Secret" from application details page in Admin Console:

Modify your API route config of Auth.js, add Logto as an OIDC provider:

Auth.js v5
Next Auth v4

./app/api/auth/[...nextauth]/route.ts
import { handlers } from '@/auth';
export const { GET, POST } = handlers;

./auth.ts
import NextAuth from 'next-auth';

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [
    {
      id: 'logto',
      name: 'Logto',
      type: 'oidc',
      // You can get the issuer value from the Logto Application Details page,
      // in the field "Issuer endpoint"
      issuer: 'https://xxxx.logto.app/oidc',
      clientId: '<logto-app-id>',
      clientSecret: '<logto-app-secret>',
      authorization: {
        params: { scope: 'openid offline_access profile email' },
      },
      profile(profile) {
        // You can customize the user profile mapping here
        return {
          id: profile.sub,
          name: profile.name ?? profile.username,
          email: profile.email,
          image: profile.picture,
        };
      },
    },
  ],
});

Replace the issuer URL with your Logto application's "Issuer endpoint".
Replace the clientId and clientSecret with your Logto application's ID and secret.
Customize the profile function to map the user profile to the Next Auth user object, the default mapping is shown in the example.

Then you can also add an optional Middleware to keep the session alive:

./middleware.ts
export { auth as middleware } from '@/auth';

app/api/auth/[...nextauth]/route.ts
import NextAuth from 'next-auth';

const handler = NextAuth({
  providers: [
    {
      id: 'logto',
      name: 'Logto',
      type: 'oauth',
      // You can get the well-known URL from the Logto Application Details page,
      // in the field "OpenID Provider configuration endpoint"
      wellKnown: 'https://xxxx.logto.app/oidc/.well-known/openid-configuration',
      authorization: { params: { scope: 'openid offline_access profile email' } },
      clientId: '<logto-app-id>',
      clientSecret: '<logto-app-secret>',
      client: {
        id_token_signed_response_alg: 'ES384',
      },
      profile(profile) {
        // You can customize the user profile mapping here
        return {
          id: profile.sub,
          name: profile.name ?? profile.username,
          email: profile.email,
          image: profile.picture,
        };
      },
    },
  ],
});

export { handler as GET, handler as POST };

Replace the wellKnown URL with your Logto application's "OpenID Provider configuration endpoint".
Replace the clientId and clientSecret with your Logto application's ID and secret.
Customize the profile function to map the user profile to the Next Auth user object, the default mapping is shown in the example.
Remember to set the id_token_signed_response_alg to ES384.

You can find more details in the Auth.js documentation.

Before we dive into the details, here's a quick overview of the end-user experience. The sign-in process can be simplified as follows:

Your app invokes the sign-in method.
The user is redirected to the Logto sign-in page. For native apps, the system browser is opened.
The user signs in and is redirected back to your app (configured as the redirect URI).

This authentication process follows the OpenID Connect (OIDC) protocol, and Logto enforces strict security measures to protect user sign-in.
If you have multiple apps, you can use the same identity provider (Logto). Once the user signs in to one app, Logto will automatically complete the sign-in process when the user accesses another app.

To learn more about the rationale and benefits of redirect-based sign-in, see Logto sign-in experience explained.

note:

In the following code snippets, we assume your app is running on http://localhost:3000/.

Let's switch to the Application details page of Logto Console. Add a Redirect URI http://localhost:3000/api/auth/callback/logto and click "Save changes".

app/components/sign-in.tsx
import { signIn } from '@/auth';

export default function SignIn() {
  return (
    <form
      action={async () => {
        'use server';
        await signIn('logto');
      }}
    >
      <button type="submit">Sign In</button>
    </form>
  );
}

app/components/sign-out.tsx
import { signOut } from '@/auth';

export function SignOut() {
  return (
    <form
      action={async () => {
        'use server';
        await signOut();
      }}
    >
      <button type="submit">Sign Out</button>
    </form>
  );
}

app/page.tsx
import SignIn from './components/sign-in';
import SignOut from './components/sign-out';
import { auth } from '@/auth';

export default function Home() {
  const session = await auth();

  return <div>{session?.user ? <SignOut /> : <SignIn />}</div>;
}

Above is a simple example, you can check the Auth.js documentation for more details.

Checkpoint

Now, you can test your application to see if the authentication works as expected.

Fetch user information

Display user information

When user is signed in, the return value of auth() will be an object containing the user's information. You can display this information in your app:

app/page.tsx
import { auth } from '@/auth';

export default async function Home() {
  const session = await auth();

  return (
    <main>
      {session?.user && (
        <div>
          <h2>Claims:</h2>
          <table>
            <thead>
              <tr>
                <th>Name</th>
                <th>Value</th>
              </tr>
            </thead>
            <tbody>
              {Object.entries(session.user).map(([key, value]) => (
                <tr key={key}>
                  <td>{key}</td>
                  <td>{String(value)}</td>
                </tr>
              ))}
            </tbody>
          </table>
        </div>
      )}
    </main>
  );
}

Request additional claims

You may find some user information are missing in the returned object from auth(). This is because OAuth 2.0 and OpenID Connect (OIDC) are designed to follow the principle of least privilege (PoLP), and Logto is built on top of these standards.

By default, limited claims are returned. If you need more information, you can request additional scopes to access more claims.

info:

A "claim" is an assertion made about a subject; a "scope" is a group of claims. In the current case, a claim is a piece of information about the user.

Here's a non-normative example the scope - claim relationship:

tip:

The "sub" claim means "subject", which is the unique identifier of the user (i.e. user ID).

Logto SDK will always request three scopes: openid, profile, and offline_access.

To request additional scopes, you can configure the params of Logto provider:

./auth.ts
import NextAuth from 'next-auth';

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [
    {
      id: 'logto',,
      // ...
      authorization: {
        params: {
          scope: 'openid offline_access profile email',
        },
      },
      // ...
    },
  ],
});

Claims that need network requests

To prevent bloating the ID token, some claims require network requests to fetch. For example, the custom_data claim is not included in the user object even if it's requested in the scopes. To access these claims, you need to make a network request to fetch the user info.

Get access token

Update the NextAuth config so that we can get the access token:

./auth.ts
export const { handlers, signIn, signOut, auth } = NextAuth({
  // ...
  callbacks: {
    async jwt({ token, account }) {
      if (account) {
        token.accessToken = account.access_token;
      }
      return token;
    },
    async session({ session, token }) {
      // Inject the access token into the session object
      session.accessToken = token.accessToken;
      return session;
    },
  },
});

Fetch user info

Now access the OIDC user info endpoint with the access token:

./app/page.tsx
// ...

export default async function Home() {
  const session = await auth();
  // Replace the URL with your Logto endpoint, should ends with `/oidc/me`
  const response = await fetch('https://xxx.logto.app/oidc/me', {
    headers: {
      Authorization: `Bearer ${session?.accessToken}`,
    },
  });
  const user = await response.json();
  console.log(user);

  // ...
}

Above is a simple example. Remember to handle the error cases.

Access token refresh

An access token is valid for a short period of time. By defualt, Next.js will only fetch one when the session is created. To implement auto access token refresh, see Refresh token rotation.

Scopes and claims

Logto uses OIDC scopes and claims conventions to define the scopes and claims for retrieving user information from the ID token and OIDC userinfo endpoint. Both of the "scope" and the "claim" are terms from the OAuth 2.0 and OpenID Connect (OIDC) specifications.

Here's the list of supported scopes and the corresponding claims:

openid

Claim name	Type	Description	Needs userinfo?
sub	`string`	The unique identifier of the user	No

profile

Claim name	Type	Description	Needs userinfo?
name	`string`	The full name of the user	No
username	`string`	The username of the user	No
picture	`string`	URL of the End-User's profile picture. This URL MUST refer to an image file (for example, a PNG, JPEG, or GIF image file), rather than to a Web page containing an image. Note that this URL SHOULD specifically reference a profile photo of the End-User suitable for displaying when describing the End-User, rather than an arbitrary photo taken by the End-User.	No
created_at	`number`	Time the End-User was created. The time is represented as the number of milliseconds since the Unix epoch (1970-01-01T00:00:00Z).	No
updated_at	`number`	Time the End-User's information was last updated. The time is represented as the number of milliseconds since the Unix epoch (1970-01-01T00:00:00Z).	No

Other standard claims include family_name, given_name, middle_name, nickname, preferred_username, profile, website, gender, birthdate, zoneinfo, and locale will be also included in the profile scope without the need for requesting the userinfo endpoint. A difference compared to the claims above is that these claims will only be returned when their values are not empty, while the claims above will return null if the values are empty.

note:

Unlike the standard claims, the created_at and updated_at claims are using milliseconds instead of seconds.

email

Claim name	Type	Description	Needs userinfo?
email	`string`	The email address of the user	No
email_verified	`boolean`	Whether the email address has been verified	No

phone

Claim name	Type	Description	Needs userinfo?
phone_number	`string`	The phone number of the user	No
phone_number_verified	`boolean`	Whether the phone number has been verified	No

address

Please refer to the OpenID Connect Core 1.0 for the details of the address claim.

custom_data

Claim name	Type	Description	Needs userinfo?
custom_data	`object`	The custom data of the user	Yes

identities

Claim name	Type	Description	Needs userinfo?
identities	`object`	The linked identities of the user	Yes
sso_identities	`array`	The linked SSO identities of the user	Yes

urn:logto:scope:organizations

Claim name	Type	Description	Needs userinfo?
organizations	`string[]`	The organization IDs the user belongs to	No
organization_data	`object[]`	The organization data the user belongs to	Yes

urn:logto:scope:organization_roles

Claim name	Type	Description	Needs userinfo?
organization_roles	`string[]`	The organization roles the user belongs to with the format of `<organization_id>:<role_name>`	No

Considering performance and the data size, if "Needs userinfo?" is "Yes", it means the claim will not show up in the ID token, but will be returned in the userinfo endpoint response.

API resources

We recommend to read 🔐 Role-Based Access Control (RBAC) first to understand the basic concepts of Logto RBAC and how to set up API resources properly.

Configure Logto provider

Once you have set up the API resources, you can add them when configuring Logto in your app:

./auth.ts
import NextAuth from 'next-auth';

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [
    {
      id: 'logto',,
      // ...
      authorization: {
        params: {
          scope: 'openid offline_access profile email',
          resource: 'https://shopping.your-app.com/api',
        },
      },
      // ...
    },
  ],
});

Each API resource has its own permissions (scopes).

For example, the https://shopping.your-app.com/api resource has the shopping:read and shopping:write permissions, and the https://store.your-app.com/api resource has the store:read and store:write permissions.

To request these permissions, you can add them when configuring Logto in your app:

./auth.ts
import NextAuth from 'next-auth';

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [
    {
      id: 'logto',,
      // ...
      authorization: {
        params: {
          scope: 'openid offline_access profile email shopping:read shopping:write',
          resource: 'https://shopping.your-app.com/api',
        },
      },
      // ...
    },
  ],
});

You may notice that scopes are defined separately from API resources. This is because Resource Indicators for OAuth 2.0 specifies the final scopes for the request will be the cartesian product of all the scopes at all the target services.

Thus, in the above case, scopes can be simplified from the definition in Logto, both of the API resources can have read and write scopes without the prefix. Then, in the Logto config:

./auth.ts
import NextAuth from 'next-auth';

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [
    {
      id: 'logto',,
      // ...
      authorization: {
        params: {
          scope: 'openid offline_access profile read write',
          resource: 'https://shopping.your-app.com/api',
        },
      },
      // ...
    },
  ],
});

For every API resource, it will request for both read and write scopes.

note:

It is fine to request scopes that are not defined in the API resources. For example, you can request the email scope even if the API resources don't have the email scope available. Unavailable scopes will be safely ignored.

After the successful sign-in, Logto will issue proper scopes to API resources according to the user's roles.

Fetch access token for the API resource

Auth.js will only fetch the access token once without resource parameter. We need to implement the access token fetching by ourselves.

Get refresh token

Update Logto provider config, add "prompt" parameter and set it to consent, and ensure offline_access scope is included:

./auth.ts
import NextAuth from 'next-auth';

export const { handlers, signIn, signOut, auth } = NextAuth({
  // ...
  authorization: {
    params: {
      prompt: 'consent',
      scope: 'openid offline_access shopping:read shopping:write',
      resource: 'https://shopping.your-app.com/api',
      // ...
    },
  },
  // ...
});

Then add a callback to save the refresh_token to the session:

./auth.ts
export const { handlers, signIn, signOut, auth } = NextAuth({
  // ...
  callbacks: {
    async jwt({ token, account }) {
      if (account) {
        // ...
        token.refreshToken = account.refresh_token;
      }
      return token;
    },
    async session({ session, token }) {
      // ...
      session.refreshToken = token.refreshToken;
      return session;
    },
  },
});

Fetch access token

With the refresh_token, we can fetch the access token from Logto's OIDC token endpoint.

./app/page.tsx
// ...

export default async function Home() {
  const session = await auth();

  if (session?.refreshToken) {
    // Replace the app ID and secret with your own, you can check the "Integration" section.
    const basicAuth = Buffer.from('<logto-app-id>:<logto-app-secret>').toString('base64');

    // Replace the URL with your Logto endpoint, should ends with `/oidc/token`
    const response = await fetch('https://xxx.logto.app/oidc/token', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
        Authorization: `Basic ${basicAuth}`,
      },
      body: new URLSearchParams({
        grant_type: 'refresh_token',
        refresh_token: session.refreshToken,
        resource: 'https://shopping.your-app.com/api',
      }).toString(),
    });

    const data = await response.json();
    console.log(data.access_token);
  }

  // ...
}

Fetch organization tokens

If organization is new to you, please read 🏢 Organizations (Multi-tenancy) to get started.

You need to add urn:logto:scope:organizations scope when configuring the Logto client:

./auth.ts
import NextAuth from 'next-auth';

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [
    {
      id: 'logto',,
      // ...
      authorization: {
        params: {
          scope: 'openid offline_access urn:logto:scope:organizations',
        },
      },
      // ...
    },
  ],
});

Once the user is signed in, you can fetch the organization token for the user:

Similar to the access token for API resources, we can use the refresh token to fetch the organization access token.

./app/page.tsx
// ...

export default async function Home() {
  const session = await auth();

  if (session?.refreshToken) {
    // Replace the app ID and secret with your own, you can check the "Integration" section.
    const basicAuth = Buffer.from('<logto-app-id>:<logto-app-secret>').toString('base64');

    // Replace the URL with your Logto endpoint, should ends with `/oidc/token`
    const response = await fetch('https://xxx.logto.app/oidc/token', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
        Authorization: `Basic ${basicAuth}`,
      },
      body: new URLSearchParams({
        grant_type: 'refresh_token',
        refresh_token: session.refreshToken,
        resource: 'urn:logto:scope:organizations',
        organization_id: 'organization-id',
      }).toString(),
    });

    const data = await response.json();
    console.log(data.access_token);
  }

  // ...
}

Prerequisites​

Installation​

Integration​

Set up Auth.js provider​

Configure sign-in redirect URI​

Regarding redirect-based sign-in​

Implement sign-in and sign-out​

Implement sign-in and sign-out button​

Show sign-in and sign-out button in the page​

Checkpoint​

Fetch user information​

Display user information​

Request additional claims​

Claims that need network requests​

Get access token​

Fetch user info​

Access token refresh​

Scopes and claims​

API resources​

Configure Logto provider​

Fetch access token for the API resource​

Get refresh token​

Fetch access token​

Fetch organization tokens​

Further readings​

Prerequisites

Installation

Integration

Set up Auth.js provider

Configure sign-in redirect URI

Regarding redirect-based sign-in

Implement sign-in and sign-out

Implement sign-in and sign-out button

Show sign-in and sign-out button in the page

Checkpoint

Fetch user information

Display user information

Request additional claims

Claims that need network requests

Get access token

Fetch user info

Access token refresh

Scopes and claims

API resources

Configure Logto provider

Fetch access token for the API resource

Get refresh token

Fetch access token

Fetch organization tokens

Further readings