getToken method returns null in vercel preview deployment

[KingPinged]

Something that works in my local development does not work when I publish to vercel on a preview. The issue is the fact that getToken returns null in the middleware function of withAuth. In the file https://github.com/nextauthjs/next-auth/blob/main/packages/next-auth/src/next/middleware.ts , the getToken method which is necessary for the functionality of withAuth returns null. The getToken method is here:

next-auth/packages/next-auth/src/jwt/index.ts

Line 67 in b3b8d4b

export async function getToken<R extends boolean = false>(

import type { NextRequest } from "next/server"
import type { JWT } from "next-auth/jwt"

import { withAuth } from "next-auth/middleware"

export default withAuth(
  function middleware(req: NextRequest & { nextauth: { token: JWT } }) {
    console.log(req.nextauth.token)
  },
  {
    callbacks: {
      authorized: ({ token }) => token?.role === "admin",
    },
  }
)

which would normally work local will always give authorized as false in deployment. I'm not sure where this error comes from. Any help would be appreciated

[JDuligall]

We had a similar issue where the tokens are stored as secured cookies, but getToken was assuming they are not secure.

const token = await jwt.getToken({
  req,
  secret,
  secureCookie: true
})

Adding the secureCookie option for getToken worked for our Vercel preview deploys.

[yassersaidi]

Thanks man, you're a life saver

[khuezy]

secureCookie should be handled as it defaults to true if your NEXTAUTH_URL starts with "https://"

[NeetishRaj]

Exactly, secureCookie:true should'nt cause any difference.

This is not a correct fix for this problem.
In my case, I am still looking for a fix.

[NeetishRaj]

I found a temporary fix for this.
For some reason decode() function inside getToken() is breaking.

I am manually decoding by getting the raw token like this.

const jwtToken = await getToken({ req, raw: true });

This works for me for now.
But, this is not a clean fix.

[BigMacEtienne]

After hours of trying to figure it out, what we found was a stackoverflow post saying to explicitly set the cookie name. We also explicitly set the secret which we haven't even tested if it works without that, but now we know this is what's working for us both locally and on deployment.

    return await getToken({
      req,
      secret: process.env.NEXTAUTH_SECRET,
      cookieName: "next-auth.session-token"
    });

[Alert360-Mohammad]

That fixed our problem after 2 days of straight debugging :)

[khuezy]

Hmm that's odd, I haven't had issues w/ this. But in any case, please be careful: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#attributes

You should be using the default __Secure- prefix in the cookie unless you know what you're getting into.