next-auth: in the middleware, the session is not extended with custom fields

@SebastianNarvaez11 @deltasierra96

I also faced this issue, what seems to have worked for me was combining my NextAuth instantiations.

The Fix

You have called NextAuth(...) in src/middleware.ts and src/auth.ts using two different configurations. I was doing a similar thing. What you will want to do is move the content of the NextAuth(...) instantiation in src/auth.ts into src/auth.config.ts so that you have one main config with all your params for NextAuth(...).

Your src/auth.ts should now look a little something like:

import NextAuth from "next-auth";
import authConfig from "@/auth.config";

export const {
  handlers: { GET, POST },
  auth,
  signIn,
  signOut,
} = NextAuth(authConfig);

Your src/auth.config.ts should now have ALL your configuration in it:

import type { NextAuthConfig } from "next-auth";
// ... Prisma Imports

export default {
  providers: [...],
  pages: {
    signIn: "/auth/login",
    error: "/auth/error",
  },
  session: { strategy: "jwt" },

  callbacks: {
    authorized({ request, auth }) {
      console.log("Please Remove Me. This is a POC", auth) // <-- This should have your additional user data!
      return true;
    },
    async session({ token, session }) {
      if (token?.data?.role && session.user) {
        session.user.role = token.data.role;
      }

      return session;
    },
    async jwt({ token }) {
      // ... Your Prisma Code

      token.data = user    

      return token;
    },
  },
} satisfies NextAuthConfig;

This should resolve the issue. I have freehand typed this in GitHub so this code will probably not be perfect and will almost 100% have at least 1 error, but the idea should be there enough to hopefully help the issue.

---

The (assumed) Root Cause

It seems the actual cause is because the instantiations are different, calling NextAuth(...) in src/middleware.ts and src/auth.ts works perfectly fine after moving all the configuration settings into one file. Thinking logically now (after rage researching all day over not being able to find the solution to this) it makes perfect sense as in the example you provided (very similar to mine) the middleware would have no idea that the session needs manipulating as the session callback is not in the config being used in src/middleware.ts

TL;DR

You need to use one configuration/NextAuth instantiation for both your providers & middleware

• Make one central auth config
• Only call NextAuth once and export all the returned objects
• Import “auth” from the previous step into the middleware
• You should now see the role in your middleware auth user data.

Just follow the full fix, its not too long…

---

I hope that fixes your issue - If this is the problem for you, it seems the problem is NOT with next-auth. It may be worth documenting this somewhere though as its (IMO) an easy mistake to make!

Big thanks to ConnorC18 for the amazing help! ⭐⭐⭐⭐⭐

es-line type issue in @AmphibianDev s case, but I believe that is because he needs to update his next-auth version

./auth.config.ts:42:30
Type error: Property 'token' does not exist on type '({ session: Session; user: AdapterUser; } | { session: Session; token: JWT; }) & { newSession: any; trigger?: "update" | undefined; }'.

  40 |   ],
  41 |   callbacks: {
> 42 |     async session({ session, token }) {

Right again, this happens on "next-auth": "^5.0.0-beta.5". After installing the "next-auth": "^5.0.0-beta.9", it disappeared. I am now fully happy! Right before, I was about to give up. 😅

@AmphibianDev I think this is almost 100% a workaround, but it seems to work and is why my one currently works. If you are running it in a non-edge environment, I think this approach is fine.

To check this actually works, I’ve made the changes and made a PR for this. Others can check the code here for an easier to read breakdown of the required changes but the explanation below might be useful

Fix PR …For AmphibianDev

https://github.com/AmphibianDev/todo-app/pull/1

auth.config.ts

  import prisma from "@/lib/prisma";
  import { NextAuthConfig } from "next-auth";
  import CredentialsProvider from "next-auth/providers/credentials";

  import { $LogInSchema } from "./lib/validation";
+ import { getUserById } from "./data/user";
+ import { PrismaAdapter } from "@auth/prisma-adapter";

  export default {
    providers: [
      // Your provider stuff from before... Nothing has changed here
    ],
+   // We have moved the callbacks into this file
    callbacks: {
      async session({ session, token }) {
        if (token.sub && session.user) {
          session.user.id = token.sub;
        }

        if (session.user) {
          session.user.id = token.sub;
          session.user.role = token.role;
        }

        return session;
      },
      async jwt({ token }) {
        if (!token.sub) return token;

-       const user = await prisma.user.findUnique({
-         where: { id: token.sub },
-       });

+       const user = await getUserById(token.sub);

        if (!user) return token;

        token.role = user.role;

        return token;
      },
    },
+   // We have moved the session into this file
    session: { strategy: "jwt", maxAge: 365 * 24 * 60 * 60 },
+   // We have moved the jwt into this file
    jwt: { maxAge: 365 * 24 * 60 * 60 },
+   // We have moved the adapter into this file
    adapter: PrismaAdapter(prisma),
  } satisfies NextAuthConfig;

auth.ts

import NextAuth from "next-auth";
import authConfig from "@/auth.config";

export const {
  handlers: { GET, POST },
  auth,
  signIn,
  signOut,
} = NextAuth({
  pages: {
    signIn: "/auth/login",
    error: "/auth/error",
  },
  ...authConfig,
});

middleware.ts

//... Other Imports
import NextAuth from "next-auth";
import authConfig from "@/auth.config";
const { auth } = NextAuth(authConfig);

export default auth((req) => {
  const { nextUrl } = req;
  const pathname = nextUrl.pathname;

  const isLoggedIn = !!req.auth;

  const isAdmin = req.auth?.user?.role === "ADMIN";
  console.log(req.auth?.user); // => { email: 'myemail@gmail.com' }
//... The rest of your code here
})

/data/user.ts

import prisma from "@/lib/prisma";

export const getUserById = async (id: string) => {
  try {
    const user = await prisma.user.findUnique({ where: { id } });

    return user;
  } catch {
    return null;
  }
};

So whats the workaround?

Basically it looks like the workaround is to import a function that calls prisma independently and then just await that function. Doing this seems to solve the issue. If this is a valid work around this 100% needs documenting, and if it is, it really needs to be made clearer.

Hey guys, I found what worked for me was to define the session callback in both auth.ts and auth.config.ts. The Credentials and other callbacks is defined in auth.ts. Now I can retrieve the custom field in the session on both the server and client as well as in the middleware.ts. I am not sure why this works, but here is the code if anyone wants to give it a try (using next-auth-5.0.0-beta.15): auth.config

import type { NextAuthConfig } from "next-auth";
export default {
  secret: process.env.AUTH_SECRET,
  pages: {
    signIn: "/login", // Define your sign-in page here
  },
  session: {
    strategy: "jwt",
    maxAge: 30 * 24 * 60 * 60, // 30 days
  },

  providers: [],
  callbacks: {
    async session({ token, session }) {
      console.log("session: ", session);
      if (token.sub && session.user) {
        session.user.id = token.sub;
      }
      if (session.user) {
        session.user.name = token.name;
        session.user.email = token.email as string;
        session.user.role = token.role;
      }
      return session;
    },
  },
} satisfies NextAuthConfig;

auth.ts

import Credentials from "next-auth/providers/credentials";
import bcrypt from "bcrypt";
import authConfig from "./auth.config";
import { findUserByEmail, getUserById } from "./data/services/user-service";
export const {
  handlers: { GET, POST },
  auth,
  signIn,
  signOut,
} = NextAuth({
  debug: true,

  ...authConfig,
  providers: [
    Credentials({
      async authorize(credentials) {
        const { email, password } = credentials;
        const existing_user = await findUserByEmail(email as string);
        if (!existing_user) return null;
        const passwordsMatch = await bcrypt.compare(
          password as string,
          existing_user.password
        );
        if (!passwordsMatch) return null;
        const user = {
          profilePicture: existing_user.profilePicture,
          id: existing_user.id,
          name: existing_user.firstName,
          email: existing_user.email,
          role: existing_user.role,
        };
        return user as User;
      },
    }),
  ],

  callbacks: {
    async session({ token, session }) {
      if (token.sub && session.user) {
        session.user.id = token.sub;
      }
      if (session.user) {
        session.user.name = token.name;
        session.user.email = token.email as string;
        session.user.role = token.role;
      }
      return session;
    },
    async jwt({ token, trigger, session, user, account }) {
      try {
        if (!token.sub) return token;
        let existingUser = null;
        if (trigger === "signIn") {
          console.log({ trigger, session, user, account });
          existingUser = await getUserById(token.sub, user.role);
        } else {
          existingUser = await getUserById(token.sub, token.role);
        }
        if (!existingUser) return token;
        token.name = existingUser.firstName;
        token.email = existingUser.email;
        token.role = existingUser.role;
      } catch (error) {
        console.log(error);
      }
      return token;
    },
  },
});

middleware.ts

import NextAuth from "next-auth";
const { auth } = NextAuth(authConfig);

export default auth((req) => {
  console.log(req?.auth?.user);
});

export const config = {
  // Match any URL that does not contain "api/auth", "_next/static", "_next/image" or "favicon.ico" at any position in the URL path.
  matcher: ["/((?!api/auth|_next/static|_next/image|favicon.ico).*)"],
};

Here are the versions of my libraries:

• prisma: 5.10.2
• @prisma/client: 5.10.2
• next: 14.1.0
• next-auth: 5.0.0-beta.15

While debugging my callbacks and middleware, I discovered the issue. It appears to be related to the prisma query on the JWT callback function, although I’m unsure why. However, placing my Prisma query within a try-catch block resolved the issue!

Here is the code:

    async jwt({ token }) {
      try {
        const query = await getUser(token.sub);
        token.role = query.role;
        token.username = query.username;
        token.avatarUrl = query.avatarUrl;
      } catch (error) {
        console.log("🚀 ~ error:", error);
      }
      return token;
    },

Hey folks, this issue seems to have gotten a bit off track…

Initially the issue was about session data not being available in middleware, right? And then it shifted towards prisma not working in edge environments. I think we’ve all gotten to the bottom of the prisma issue, right? If not, here’s my current understanding - using prisma@5.9.1+, session: { strategy: 'jwt' } and not doing any database calls with prisma in your middleware or other edge runtime environments should work as of now with the latest versions of everything. Right? I’m pretty sure you no longer have to do the split config thing either since as of prisma@5.9.1 they changed when the errors throws (query time vs. client instantiation).

Regarding the middleware req.auth issue, I’ve just double checked with the latest next-auth@5.0.0-beta.15 and req.auth is available with both OAuth and Credential providers when setup like how the docs describe:

import { auth } from "./auth"

export default auth((req) => {
  console.log("middleware.auth", !!req.auth)
})

export const config = {
  matcher: ["/((?!api|_next/static|_next/image|favicon.ico).*)"],
}

If you’re having problems that aren’t related to the original middleware session issue, please open a new issue.

---

To the latest commenters, @SebastianNarvaez11 this is an error you’re throwing yourself because your getUserById funciton is not findign the user, correct? In the case of credentialsProvider, the token.sub defaults to the profile.id. So make sure yuo’re returning at least an id from your authorize fn.

You can enable debug: true in the auth config and see what token.sub you’re getting back from the provider, or simply log it in your getUserById. Then you can manually confirm that you have a user in your database with that ID. Is that all good so far?

@renatoastra can you provide more details about your setup and which versions of next-auth and next.js you’re using?

Thanks everyone 🙏

Hi @ConnorC18. Thanks for helping out @AmphibianDev with the PR. Appreciate it!!

A quick question: Is Prisma actually running on middleware using this approach? I have my doubts since Prisma is not edge-compatible. Are you able to build the project using npm run build ?

No worries! So, I am exclusively looking at this from a Non Edge standpoint, as that is what myself and @AmphibianDev are both using in this case. As far as I can see, it builds fine and runs (with the exception of the session callback having a es-line type issue in @AmphibianDev s case, but I believe that is because he needs to update his next-auth version, as I do not have this issue with the same approach). After building, the following successful output can be seen for @AmphibianDev s project

Hi everyone. Here’s a thumb rule you can follow:

1. Define all config in a single place - auth.config.ts
2. In auth.ts export the following:

export const { handlers, auth, signIn, signOut } = NextAuth({...authConfig})

1. Use the exported handlers in /api/auth/[...nextAuth]/app.ts.

All is good until you want to add middleware.ts.

Now you should be able to use the same exported auth from auth.ts but since there are adapters that are not compatible with middleware, you cannot use them YET. I am trying to use postgres with drizzle-orm and at the time of writing this, only neon serverless has a postgres connector.

How did I resolve this?

I moved the adapter and any callbacks requiring DB access into auth.ts. I had to reinitialize NextAuth in middleware as follows:

import NextAuth from 'next-auth'

import { authConfig } from './auth.config'

const auth = NextAuth(authConfig).auth

export default auth((req) => {
// Do some routing stuff here if you want
// The `req.auth` will have all the fields that you returned via the `session` callback
})

Use the above hack until the adapters support running on edge. BTW - I spent 2 days setting up the Next Auth v5. I finally completed it. Here are my thoughts:

1. The current documentation state is not good. Refer to this video for any setup-related issues: https://www.youtube.com/watch?v=1MTyCvS05V4&t=15629s. Shoutout to whoever created this.
2. After setup, things are much simpler and easier to handle.
3. I even created my adapter because of my requirements using drizzle.
4. AdapterModels should be implemented in a way that we can override stuff. I needed my userId to be an integer, which is not possible at all without raising a bunch of errors in NextAuth. Used the cal.com GitHub repo to understand how to do this.

Hi everyone. Here’s a thumb rule you can follow:

1. Define all config in a single place - auth.config.ts
2. In auth.ts export the following:

export const { handlers, auth, signIn, signOut } = NextAuth({...authConfig})

1. Use the exported handlers in /api/auth/[...nextAuth]/app.ts.

All is good until you want to add middleware.ts.

Now you should be able to use the same exported auth from auth.ts but since there are adapters that are not compatible with middleware, you cannot use them YET.

How did I resolve this?

I moved the adapter and any callbacks requiring DB access into auth.ts. I had to reinitialize NextAuth in middleware as follows:

import NextAuth from 'next-auth'

import { authConfig } from './auth.config'

const auth = NextAuth(authConfig).auth

export default auth((req) => {
// Do some routing stuff here if you want
// The `req.auth` will have all the fields that you returned via the `session` callback
})

Use the above hack until the adapters support running on edge. BTW - I spent 2 days setting up the Next Auth v5. I finally completed it. Here are my thoughts:

1. The current documentation state is not good. Refer to this video for any setup-related issues: https://www.youtube.com/watch?v=1MTyCvS05V4&t=15629s. Shoutout to whoever created this.
2. After setup, things are much simpler and easier to handle.
3. I even created my adapter because of my requirements using drizzle.
4. AdapterModels should be implemented in a way that we can override stuff. I needed my userId to be an integer, which is not possible at all without raising a bunch of errors in NextAuth. Used the cal.com GitHub repo to understand how to do this.

Im currently battleing this behaviour too, fighting it for 6 days now. Can you please share your code so we can see what was done in order to get this going? I have tried using prisma - only with accelerate which is paid, drizzle - “edgeFunction is not defined”.

@AmphibianDev

If I move the callbacks: {...} or the adapter: PrismaAdapter(prisma) from auth.js into the auth.config.js

Also make sure you are copying over session: { strategy: "jwt" }, into the auth.config.js as not having this in the config while adapter: PrismaAdapter(prisma) is present might also cause this issue.

@AmphibianDev make sure you are not calling prisma in the middleware.ts handler. I don’t believe this error is caused by the PrismaAdapter; the PrismaClient causes it. Just make sure you are not using prisma in the middleware

Thanks for reporting, and thanks @ConnorC18 for explaining, that is exactly what we recommend at the moment. Some of us are working on a new doc to address this use-case, cc @ndom91 @ubbe-xyz 🙏