nextauthjs
/auth/session duplicate Set-Cookie header
Environment
System: OS: Linux 5.15 Ubuntu 24.04 LTS 24.04 LTS (Noble Numbat) CPU: (4) x64 AMD Ryzen 7 3700X 8-Core Processor Memory: 14.34 GB / 15.62 GB Container: Yes Shell: 5.2.21 - /bin/bash Binaries: Node: 18.19.1 - /usr/bin/node npm: 9.2.0 - /usr/bin/npm npmPackages: @auth/unstorage-adapter: ^2.0.0 => 2.2.0 next: latest => 14.2.4 next-auth: beta => 5.0.0-beta.19 react: ^18.2.0 => 18.3.1
Also experienced in: node:22-alpine Docker environment w/ "react": "18.3.0", "next": "^14.2.3", "next-auth": "^5.0.0-beta.19",
Reproduction URL
https://github.com/Rikaelus/nextauth-bug-cookies
Describe the issue
Post-authentication calls to /auth/session result in two authjs.session-token cookies being set in the HTTP headers. While they have different hash values I believe they ultimately store the same underlying information and their difference is consistently just one bite. I've witnessed this with both the CredentialsProvider (as in the example project) and a custom OIDC provider.
Calls to similar endpoints, such as /auth/providers only returns the single cookie.
This is particularly problematic with larger cookies (our actual use case is just shy of 4K) due to the double cookies exceeding our load balancer header size allowances.
How to reproduce
- Download and start attached project
- Log in with the lone credentials configuration (will yield a workable session, albeit with no user data)
- Proceed directly to http://localhost:3000/auth/session and review response headers/cookies.
Expected behavior
A lone authjs.session-token cookie being set.
I have the same issue. Did you manage to fix it?
I did not. We ended up having to spin up an entirely separate HTTP1-based load balancer on OCI so we could expand the allowed HTTP header size.
Similar issue being experienced in my organization. But cookie is actually triplicated. This is only happening on certain paths of the service, so we are looking into it possibly being a bad implementation of a callback function from our part. If not I will bring more details.
The issue is reproducible in the latest v5 beta if you try to sign in while already signed in.
It may not be an issue for most of cases, because sign-in page typically is hidden from authenticated users. But in my case we have 2 providers and 2 types of session: guest and authenticated. We use Akamai as a proxy and it has response headers limit 8kb and it causes 502 error when guest user tries to log in.
Any thoughts about how to avoid duplicate session token cookie?
@balazsorban44 can you please advise here? Thanks in advance.
An immediate solution would be to disable middleware via the matcher config for the paths that experience this double setting issue.
http://localhost:3006/api/auth/callback/credentials create large amount of cookies.
http://localhost:3006/api/auth/callback/credentials create large amount of cookies.
fixed. put too much data (user's avatar image) into session.