Session issues in production: /api/auth/session returns empty {} but works in development

[tayloraucoin]

Environment

 System:
    OS: macOS 12.5
    CPU: (10) arm64 Apple M1 Pro
    Memory: 79.56 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 20.10.0 - ~/.nvm/versions/node/v20.10.0/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 10.2.3 - ~/.nvm/versions/node/v20.10.0/bin/npm
  Browsers:
    Chrome: 128.0.6613.115
    Edge: 128.0.2739.63
    Safari: 15.6
  npmPackages:
    next: 14.2.5 => 14.2.5 
    next-auth: ^4.24.7 => 4.24.7 
    react: ^18 => 18.3.1 

Reproduction URL

https://github.com/tayloraucoin/next-auth-prisma-undefined-bug

Describe the issue

This is the step-by-step flow of the feature that is causing issues:

1. A user is generated through a checkout process.
2. A JWT-encoded token is generated for the user.
3. The user receives an email with a verification link that includes the token.
4. When they land on the sign-up page, the token is decoded.
5. A next-auth.session-token cookie is created and returned in the verify-token response, mimicking next-auth’s native sign-in behavior.
6. The session state is refreshed using getSession, which sends a verification request to next-auth.
7. The request to /api/auth/session is where the issue occurs in production—this endpoint returns {}, while it works as expected in development.

We are encountering session issues in production on Vercel with the Next.js app using next-auth. The issue arises during the getSession call, which fails to return a valid session. The session API request (/api/auth/session) is returning {}, and no session data is being retrieved for authenticated users, even though the cookies are properly set.

In development, everything works as expected, and the getSession call successfully retrieves the session data. However, in production, the same logic results in an empty object being returned, and the user remains unauthenticated.

We have used the encode and decode functions provided by next-auth to set a next-auth.session-token cookie in the browser after validating a token passed in a URL query string. This setup works as expected in development but fails in production.

I have tried adjusting cookie settings (e.g., SameSite, secure), but it does not resolve the issue.

Important: The callback functions with the nextauth setup are not being called in production. Only the redirect callback is. However, in development, I can see the jwt and session callbacks are properly triggered. The absence of these callbacks is the biggest clue to what is going on. See ./app/api/auth/[...nextauth]/route.ts for reference.

How to reproduce

Using the https://github.com/nextauthjs/next-auth-example template provided forces version 5. When trying to set next-auth to my actual version, several things broke. NextAuth from next-auth/next does not work in version 5. This has been frustrating, as the template is meant to save time. This example repo is also used for another issue with the Prisma adapter: #11773

In the setup, you can navigate to http://localhost:3000/checkout-simulate, enter an email, and click submit. This creates a user, generates an encoded JWT token, and produces a URL that redirects to /sign-in?token=${token}.

On the sign-in page, the token is read and sent to the /api/auth/verify-token endpoint for decoding and verification. This step works successfully, and the auth cookie is saved correctly. However, the /api/auth/session request still returns an empty session {} in production, even though everything works as expected in development.

Expected behavior

In production, the /api/auth/session endpoint should return the proper session data as it does in development. The session callbacks should be triggered in production as they are in development.

[tayloraucoin]

For added context, here is the network request in question, where the sufficient request is made but only an empty response is returned.

To emphasize, this request triggers the jwt and session callbacks in development, but does not in production.

[tayloraucoin]

@balazsorban44 why was this converted into a discussion? This seems to be a legitimate issue.

[praveenkumar-TU]

any solutions so far?