How to invalidate/delete sessions for CredentialsProvider

[EvHaus]

I am using CredentialsProvider and Prisma to store my users. Everything works great except for 1 problem. If I delete a user from my database (ie. I want to block their access to my app), next-auth doesn't force their session to get logged out. When that user refreshes the page, it lets them get all the way through because it continues to use their JWT cookie token.

Looking through the various next-auth issues, discussions & docs I feel like I'm stuck in an infinite loop.

• I thought about resetting their session by destroying their session data. This would be possible if I was using session.strategy = "database" but when I set it I run into CALLBACK_CREDENTIALS_JWT_ERROR and the docs say I can't use CredentialsProvider with the "database" strategy -- it must be JWT. So that's a dead end.
• I could try to invalidate their JWT somehow in the code, but based on this comment it sounds like there's no supported way for that either. The only solution offered is to set a short expiry date, but that's not secure enough for me. I need the session to be invalidated IMMEDIATELY after I block/delete this user, I can't allow them to gain access any further.

I think my ideal solution would be to do something like this in the session callback where I'm already checking for the existence of a user:

export default NextAuth({
	...
	callbacks: {
		session: async ({session, token}) => {
			// Check if user exists in database
			const dbUser = await prisma.user.findFirst(...);

			// If the DB user doesn't exist anymore (ie. user was deleted)
			// -- revoke the session (aka. return null). Unfortunately next-auth
			// doesn't support returning null here to revoke a session. It throws
			// an error instead. :(
			if (!dbUser) return null;

			return session;
		},
	},
});

The only possible solution I have found so far is to manually do a check for session.user EVERYWHERE in my app where I call useSession(). This is what I'm doing to workaround this limitation, but man-oh-man -- this is really awful as it causes so much code duplication and is super risky in terms of security. What if I miss a spot...

Is there any other possible solution here? What's the reason I can't use "database" strategy with CredentialsProvider? That seems like it would give me exactly the type of control that I need.

[Kukiezi]

I was also struggling with this issue just now, and having a solution built in would be great. That being said, the workaround you mentioned can be simplified a bit with error message and a simple wrapper for client side.

In callback I get a user from db, and check if he is Active. If not, I would attatch error message to the session object.

 async session(props) {
            const user = await getUser()
            
            if (user?.isActive === false) {
                props.session.error = "inactive-user"
            }

            props.session.token = props.token
            return props.session;
 },

In client side I create a wrapper, that we can put around secure routes to signOut user if error is available in session object:

import { signOut, useSession } from "next-auth/react";
import { useRouter } from "next/router";
import { useEffect } from "react";

type Props = {
    children: React.ReactNode
}

export const Auth = ({ children }: Props) => {
    const { data: sessionData } = useSession();
    const router = useRouter();

    useEffect(() => {
        if (sessionData?.error === "inactive-user") {
            // Sign out here
            signOut();
        }
    }, [sessionData?.error, router]);

    return (
        <>{children}</>
    )
}

Not ideal, but at least a simplification. Hope it helps someone!
Original source: https://stackoverflow.com/a/71608606

[itsanishjain]

But this won't delete the

next-auth.session-token

if some how we delete this session variable than

useSession() return status as unauthenticated.

[itsanishjain]

I am using CredentialsProvider and Prisma to store my users. Everything works great except for 1 problem. If I delete a user from my database (ie. I want to block their access to my app), next-auth doesn't force their session to get logged out. When that user refreshes the page, it lets them get all the way through because it continues to use their JWT cookie token.

Looking through the various next-auth issues, discussions & docs I feel like I'm stuck in an infinite loop.

• I thought about resetting their session by destroying their session data. This would be possible if I was using session.strategy = "database" but when I set it I run into CALLBACK_CREDENTIALS_JWT_ERROR and the docs say I can't use CredentialsProvider with the "database" strategy -- it must be JWT. So that's a dead end.
• I could try to invalidate their JWT somehow in the code, but based on this comment it sounds like there's no supported way for that either. The only solution offered is to set a short expiry date, but that's not secure enough for me. I need the session to be invalidated IMMEDIATELY after I block/delete this user, I can't allow them to gain access any further.

I think my ideal solution would be to do something like this in the session callback where I'm already checking for the existence of a user:

export default NextAuth({
	...
	callbacks: {
		session: async ({session, token}) => {
			// Check if user exists in databse
			const dbUser = await prisma.user.findFirst(...);

			// If the DB user doesn't exist anymore (ie. user was deleted)
			// -- revoke the session (aka. return null). Unfortunately next-auth
			// doesn't support returning null here to revoke a session. It throws
			// an error instead. :(
			if (!dbUser) return null;

			return session;
		},
	},
});

The only possible solution I have found so far is to manually do a check for session.user EVERYWHERE in my app where I call useSession(). This is what I'm doing to workaround this limitation, but man-oh-man -- this is really awful as it causes so much code duplication and is super risky in terms of security. What if I miss a spot...

Is there any other possible solution here? What's the reason I can't use "database" strategy with CredentialsProvider? That seems like it would give me exactly the type of control that I need.

This is the exact question I have though I think of deleting

next-auth.session-token

[mkbctrl]

Since I spent some time with that issue, I have a different solution here. Not a perfect one, that kind would have to be implemented next-auth side I think, still...

I have JWT strategy. In the beginning I tried the approach with returning session error as suggested above, but it has a certain problem. If your user token will be revoked externally, for example Admin will sign you out, or backend will destroy the session NextAuth won't be notified in any way until you either call session endpoint or your token expires and you will attempt to refresh it.
So until NextAuth make a move you will live in a perfect world where the token is supposed to be valid.

If your backend offers pub-sub solution like AWS Cognito Hub, than you can try to build your guard around listening to global events and react to them. It was my initial attempt, but I am too dumb to force Hub working client-side, and server side does work, but still there is no way to programmatically trigger the signout, so again I got stuck ( if anyone reading it know how to make Hub work client side in Nextjs, please lemme know -> setting up Hub inside useEffect failed hard after recent updates they made to it or again -> too dumb to comprehend).

So... Network! Network layer will let you know if your token fails to authorize your GET/POST... requests, and that's smth you can rely on. From my perspective it's far more reliable than useEffect.

Since I am using axios, I added error handler inside my response interceptor and I was done:

api.interceptors.response.use(
  async (response) => {
    return response
  },
  ({ response }: { response: AxiosResponse }) => {
    if (response.status === 401) {
      autoSignOut()
    }
  }
)

export const autoSignOut = async () => {
  // check if cookie says signOut in progress
  try {
    // set progress cookie
    await signOut()
    
  } catch (error) {

  }

// remove progress cookie
}

Since error can trigger multiple times if you are using smth like react-query under the hood I use cookies to store the state of the signout process. If it's pending I early return in order not to flood user with too many toast messages.

[iiiok]

Next-Auth Session-token issues have been hindering me for half month.
Some time, unable to getSession after Login, some time unable to logout.

Here is how it solved, update Ur next-auth library AND the NEXT library as well !
"next": "^13.3.1",
"next-auth": "^4.22.1",

[abrahamtorres10]

yes !, that worked for me, i was struggling for hours

[daniellin215]

Do we need next js 13 for this to work?

[raoufswe]

I'm facing a similar issue with the GoogleProvider. when User A is logged in, and User B is about to log in (in my case, it's an invitation page with Google Sign-In). The next-auth session still points to User A's session, even though the Google Sign-In for User B is successful. It's not the most elegant solution, but my workaround is to attach a query parameter to the callbackUrl and then make sure to call signOut on the client side to clear the current session before proceeding.

  signIn("google", {callbackUrl: `/invitation?gaSuccessCb=true` })

  useEffect(() => {
    if (data && status === "authenticated" && !query.gaSuccessCb;) signOut();
  }, [status, data, query.gaSuccessCb]);

[jasondainter]

Would love to see a better solution for this and have similar issues. Forcing people to use JWT for CredentialsProvider is one thing, but not being able to kick out those users (eg if they are bad actors) easily is really another.

Is there any movement at all to allowing CredentialsProvider to be used with database strategy or is that a dead end?

There is a workaround to this here that apparently will let you store the ProviderCredentials in the session in the DB, but its super complicated and veers quite far away from the core functionality of NextAuth which isn't optimal.

[bangsyir]

@EvHaus in my case, i used nextjs 13 (pages)... i found the solution, at least for now.
just keep callback session like normal.

first create /api/auth/me endpoint

import { NextApiRequest, NextApiResponse } from "next";
import { getServerSession } from "next-auth";
import { authOption } from "./[...nextauth]";
import { db } from "@/server/db";

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  if (req.method === "GET") {
   // you can use getToken()
    const session = await getServerSession(req, res, authOption);
    if (!session) {
      return res.status(401).json({ code: "UNAUTHORIZED" });
    }

    const user = await db.user.findUnique({
      where: {
        // I initialize the id as a sub on the session token
        id: session?.user?.sub 
      },
    });
    if (!user) {
      return res.status(401).json({ code: "UNAUTHORIZED" });
    }
    res.status(200).json({ code: "OK", data: { ...user } });
  }
}

after that check the end-point /api/auth/me using nextjs middleware

import { NextResponse, type NextRequest } from "next/server";

// check if user is authorized
const getUser = async (req: NextRequest) => {
  const user = await fetch("http://localhost:3000/api/auth/me", {
    headers: {
      Cookie: req.cookies as any,
    },
  }).then((res) => res.json());
  return user;
};

export default async function middleware(request: NextRequest) {
  const user = await getUser(request);
  const path = request.nextUrl.pathname;
  // reject unauthorized user
  if (user.code === "UNAUTHORIZED" && path.includes("/dashboard")) {
    return NextResponse.redirect(new URL("/login", request.url));
  }
  if (user.code === "OK" && path === "/login") {
    return NextResponse.redirect(new URL("/dashboard", request.url));
  }
}

// middleware only run on specific paths
export const config = {
  matcher: ["/login", "/dashboard/:path*"],
};

every time the status code is 401 ("UNAUTHORIZED"), the server automatically deletes the next-auth.session-token cookie.

[Mcdonamj087]

@bronz3beard afaik, this doesn’t really solve the issue of there still being a valid session user. I took the same approach as you whereby inside of the authorized callback in my withAuth middleware, I query the db to check if user exists. If they don’t, I return false and this will redirect them back to the signin page. On my custom signin page though, I have logic that checks the session (using getServerSession) which again redirects folks back to my protected dashboard - so because we are not able to invalidate the actual session itself, it’s an infinite loop of redirects. How are you handling this?

[bronz3beard]

I can remove the DB session and session cookie before I return false.
Since this message I implemented another approach without auth wrapper and callback 👍

[taylor-lindores-reeves]

@bronz3beard please can you share how you are able to delete the database session?

[maliesa96]

@bronz3beard +1, curious to see the other method

[maxiCalderonBuono]

@bronz3beard Hi, could you please share with us, your approach and solution to this problem?

[bronz3beard]

Sorry for the delay everyone, with works and the 1 million notifications on 100 different platforms github notifications goes unnoticed.
In the end my solution for my problem I think has moved away from this topic, but I will share what I have to inspire some thinking.

NOTE:: I am not longer using the nextAuth wrapper in the auth config.

Some tech info:
"prisma": "^5.3.1",

• import { PrismaClient } from '@prisma/client/edge'
• "@prisma/client": "^5.4.1"
• "@prisma/extension-accelerate": "^0.6.2"
"next": "^13.4.19",
"next-auth": "^4.23.2",

DB setup:
user related tables

• users
• buyers
• sellers

Resources:

1. user table setup I followed this -> nextjs-prisma-postgres
2. database-access-on-the-edge
3. next-auth-example

pages/api/[...nextauth].ts

    async redirect({ baseUrl }) {
      return `${baseUrl}/home`
    },
    async session({ session, user }) {
      const completeUser: User = user as unknown as User

      return {
        ...session,
        user: {
          ...completeUser,
        },
      }
    },
  },

---

pages/api/currentSessionUser.ts

import { NextApiRequest, NextApiResponse } from 'next'
import { getServerSession } from 'next-auth'
import prismaExtended from '~/lib/prisma'
import { authOptions } from './[...nextauth]'

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  if (req.method === 'GET') {

    const session = await getServerSession(req, res, authOptions)
    if (!session) {
      return res.status(401).json({ code: 'UNAUTHORIZED' })
    }

    const userToUpdate = await prismaExtended.user.findUnique({
      where: {
        email: session?.user?.email || '',
      },
      select: { id: true, email: true, buyer: true },
      cacheStrategy: { ttl: 60 },
    })

    const hasBuyer = await prismaExtended.buyer.findUnique({
      where: { email: userToUpdate?.email as string },
    })

    if (hasBuyer) {
      await prismaExtended.buyer.updateMany({
        where: { email: hasBuyer.email, deleted: { not: null } },
        data: { deleted: null, ...(userToUpdate?.id && { authId: userToUpdate.id }) },
      })

      if (userToUpdate?.buyer?.email !== hasBuyer.email) {
        await prismaExtended.user.update({
          where: { email: hasBuyer.email, buyerEmail: null },
          data: { buyerEmail: hasBuyer.email },
        })
      }
    }

    const user = await prismaExtended.user.findUnique({
      where: {
        email: userToUpdate?.email || '',
      },
      select: { buyer: true },
      cacheStrategy: { ttl: 60 },
    })
    
    if (!user) {
      return res.status(401).json({ code: 'UNAUTHORIZED' })
    }
    res.status(200).json({ code: 'OK', data: { ...user } })
  }
}

middleware.ts

const getUser = async (req: NextRequest): Promise<UserApi> => {
  const { data: user } = await fetch(`${req.nextUrl.origin}/api/auth/me`, {
    headers: {
      // eslint-disable-next-line @typescript-eslint/no-explicit-any
      Cookie: req.cookies as any,
    },
  }).then((res) => res.json())

  return user
}

const middleware = async (request: NextRequest) => {
  const user: UserApi = await getUser(request)
  const token = request.cookies.get('next-auth.session-token')

  const pathnameSegments = request.nextUrl.pathname.split('/')
  const currentAppPath = getCurrentAppPath(pathnameSegments)
  const currentAction = getCurrentAction(pathnameSegments)

  // if the user is not on the home page AND there is no user object or token redirect the user to auth page.
  if (currentAppPath !== AppPath.home && (!user || !token)) {
    return NextResponse.redirect(new URL('/api/auth/signin', request.url))
  }

  // If the user is authed and on the home page AND has not created a user profile redirect the user to create a profile type.
  if (
    currentAppPath === AppPath.home && !user?.agent
      ? currentAppPath === AppPath.home && !user?.buyer
      : currentAppPath === AppPath.home && !user?.agent
  ) {
    return NextResponse.redirect(new URL('/select-profile-type', request.url))
  }

  if (currentAppPath && currentAction) {
    const allowedRoles = PERMISSIONS[currentAppPath as AppPathType][currentAction as Actions]

    const userType: UserType = user?.buyer?.type || user?.seller?.type

    if (!allowedRoles.includes(userType)) {
      return NextResponse.redirect(new URL('/', request.url))
    }
  }
  return NextResponse.next()
}

export default middleware

when user deletes account

  const handleDeleteUserAccount = async () => {
// TODO:: remove this I dont think I need it ??
    // const signOutResponse = await signOut({ redirect: false, callbackUrl: `/${AppPath.home}` })
    // console.log(
    //   '🚀 ~ file: index.tsx:248 ~ handleDeleteUserAccount ~ signOutResponse:',
    //   signOutResponse,
    // )
    // // P2025 DeleteSessionError
    const response = await fetcher<unknown, { id: number | undefined }>(
      `${endPoint}/delete-user-account/${userTypes[userType]}`,
      { id: data?.id },
      'POST',
    )

    // if a date timestamp is returned the user has successfully been deleted.
    if (response) {
      router.push(`/${AppPath.home}`)
    }
  }

pages/api/delete-user-account

import { NextApiRequest, NextApiResponse } from 'next'
import { getServerSession } from 'next-auth/next'
import prismaExtended from '~/lib/prisma'
import { authOptions } from '../../auth/[...nextauth]'

const userDeleteHandler = async (req: NextApiRequest, res: NextApiResponse): Promise<void> => {
  const session = await getServerSession(req, res, authOptions)

  if (session) {
    const { body, query, method } = req
    const userId = body.id

    switch (method) {
      case 'POST':
        try {
          if (query.userType === 'buyer') {
            const data = await prismaExtended.buyer.delete({
              where: {
                id: userId,
              },
            })

            await prismaExtended.user.delete({
              where: {
                id: data.authId,
              },
            })

            const buyer = { buyer: data.deleted }

            return res.status(200).json(buyer)
          }
        } catch (error: unknown) {
          console.error('🚀 ~ file: index.ts ~ line 45 ~ error', error)
          // throw error for errorWrapper to handle?
          // send to some error logging service?

          const commonError = error as unknown as object
          return res.status(500).json({
            error: {
              ...commonError,
              message: '',
            },
          })
        }

        break
      default: {
        res.setHeader('Allow', ['OPTIONS'])
        res.status(405).end(`Method ${method} Not Allowed`)
      }
    }
  } else {
    res.send({
      error: 'You must be signed in to view the protected content on this page.',
    })
  }
}

export default userDeleteHandler

In the end the user row is deleted from the database I am using prisma.$extends to soft delete buyer/seller data and then reuse it later if the user comes back with the same email address.
When The user deletes their account they are redirected back to auth page, and the session is removed.

Session table before delete

Session table after delete

At this stage I am still in development of this side project, I have not done much analysing of the code yet, so I have dumped some code here have a think about it ask me questions I will also have a think about it, and if any of this code is useful or my approach is useful for you please take it and run with it, I think if you have questions about the code please copy paste the code snippet and then ask your question.

If you think this code is rubbish that is fair, I have no attachment to it do if you want to help me improve it please share.

Cheers 🍻

P.S. if this code looks like gibberish let me know I will add some clarity to the parts you are interested in.

[Maliksidk19]

I see you are checking the cookie name in middleware "next-auth.session-token". but on production this will not be the name of cookie so it won't work on production ig

[bronz3beard]

yes, honestly I dont remember the outcome of this code I wrote, but it did evolve after messaging in this thread, I will see where that code is and share again maybe it is still useful.

[lacymorrow]

I handled setting the cookie manually using app router and authjs v5 recently:

import { encode } from "next-auth/jwt";
import { cookies } from "next/headers";
import { redirect } from "next/navigation";
import { defaultCookies } from "node_modules/@auth/core/lib/utils/cookie";

///
  const { token, user } = jwtResponse;

  // Sign in the new user by generating a token manually...
  const newToken = await encode({
    token: { ...token, user, expiration: new Date().toISOString() },
    secret: env.NEXTAUTH_SECRET!,
    salt:
      process.env.NODE_ENV === "production"
        ? "__Secure-authjs.session-token"
        : "authjs.session-token",
  });

  // ...and setting it as a cookie
  const secure = process.env.NODE_ENV === "production";
  const { name, options } = defaultCookies(secure).sessionToken;
  cookies().set(name, newToken, options);

  return redirect(redirectTo);

[Blazskills]

I expire the token instantly, I get an unauthorized or 401 error. I set the expiration date to now . That is the only strategy I'm currently using.

token.expiresIn = Date.now()

[aadrianras]

Where are you expiring the token? In the JWT or session callback?

[zivtamary]

is there any fix for this?

[Maliksidk19]

btw I'm using "next": "14.2.3", "next-auth": "^5.0.0-beta.18"

[Blazskills]

how did you implement the refresh token

[Maliksidk19]

I have not setuped the refresh token, but I'm using the maxAge for the session token age and updateAge to update after every 1 day, if that's what you are asking

  session: {
    strategy: "jwt",
    maxAge: 86400,
    updateAge: 86400
  },

[Maliksidk19]

https://authjs.dev/guides/refresh-token-rotation#database-strategy

checkout this page for implementing the refresh token

[sanneh2]

    async jwt({ token }) {
      const user = await getUserById({ id: token.sub! });
      if (user.error) return null

      token.user = user
      return token;
    },
    async session({ session, token }) {
      if (token) {
        // @ts-ignore
        session.user = token.user;
      }
      return session;
    },

just perform any action you are doing in jwt and if it fails just return null and in session check if token is present then only return session,user else session will be deleted automatically

Good job. This is a good solution to invalidating the session on the server based on mutations on the server. I am not sure how efficient it is, and how many calls are made to the db in this way, but for example, it is better if you are not using client side session updates, which requires setting up a session provider, etc.

[deelo55]

I'm using "next-auth": "^4.24.7", and if I throw an error in either the jwt or session callbacks, the token is removed on the client and the session status changes to "unauthenticated"

[deelo55]

also returning null has the same effect

[Maliksidk19]

That's the normal way, if you send null or throw error then your session is gone, can you tell me what exactly you want to acheive ?

[deelo55]

Just saw you suggested the same above. Would be great to update the documentation to make this behaviour clearer.

[190km]

hey, can you show an exemple of code ? I tried to return null in the session if i cant get the user from the database, and i cant login.

[Maliksidk19]

hey, can you show an exemple of code ? I tried to return null in the session if i cant get the user from the database, and i cant login.

async jwt({ token }) {
  const user = await getUserById({ id: token.sub! });
  if (user.error) return null

  token.user = user
  return token;
},
async session({ session, token }) {
  if (token) {
    // @ts-ignore
    session.user = token.user;
  }
  return session;
},

take a look at this, if this helps

[jvnm-dev]

Next 14 here. I wanted to sign out on 401 here is my solution.
I am using axios.

• Intercept 401

axios.interceptors.response.use(undefined, (error) => {
      if (axios.isAxiosError(error)) {
        if (error.response?.status === 401) {
          redirect("/sign-out");
        }
      }

      return Promise.reject(error);
});

• Create a sign-out endpoint

"use client";

import { signOut } from "next-auth/react";
import { useEffect } from "react";

const SignOut = () => {
  useEffect(() => {
    void signOut();
  }, []);

  return null;
};

export default SignOut;

I guess that could be also done with route handlers and cookie deletion.

[EvHaus]

Personally I was never able to find any solution to this in next-auth. I moved all my apps to lucia-auth.com instead. It gives you full control over sessions and tokens, and I've been very happy with it.

[skulden13]

Maybe this could be helpful to solve this issue #5334 (comment)