next-auth
next-auth copied to clipboard
next-auth is not working with Next 12.2.3
Environment
System:
OS: Windows 10 10.0.22000
CPU: (8) x64 Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz
Memory: 2.23 GB / 15.94 GB
Binaries:
Node: 16.13.0 - ~\scoop\apps\nvm\current\nodejs\nodejs\node.EXE
Yarn: 1.22.19 - ~\scoop\apps\yarn\current\bin\yarn.CMD
npm: 8.1.0 - ~\scoop\apps\nvm\current\nodejs\nodejs\npm.CMD
Watchman: 20210110.135312.0 - C:\ProgramData\chocolatey\bin\watchman.EXE
Browsers:
Edge: Spartan (44.22000.120.0), Chromium (103.0.1264.62)
Internet Explorer: 11.0.22000.120
npmPackages:
next: latest => 12.2.3
next-auth: latest => 4.10.2
react: ^18.2.0 => 18.2.0
Reproduction URL
https://github.com/RafalFilipek/next-auth-bug
Describe the issue
After login, you get login page again. Cookies are set and everything looks good. But you can't access your app. It works with 12.2.2
and below.
How to reproduce
- clone
https://github.com/RafalFilipek/next-auth-bug
- setup any provider in
[...nextauth].ts
- try to login
Expected behavior
Login process should work as expected.
I believe I ran into the same issue, downgrading to next 12.2.2 appears to have fixed my problem.
When accessing the token in middleware.ts, the token was always null, even though console logs of the jwt callback showed the token as valid. And if you return true
inside middleware, all auth functionality appears to work normally.
Here is the middleware.ts I was using.
import { withAuth } from 'next-auth/middleware';
export default withAuth({
callbacks: {
authorized: ({ token, req }) => {
if (!token) return false;
if (req.nextUrl.pathname.startsWith('/admin')) return token.isAdmin;
return true;
},
},
});
I've tested [email protected] and can confirm this is an issue, not sure about the root cause though. @balazsorban44 maybe you could tell if this is an upstream issue?
Hmm. @ThangHuuVu might be right. I am able to reproduce this starting with 12.2.3-canary.17
, so something might have happened in https://github.com/vercel/next.js/compare/v12.2.3-canary.16...v12.2.3-canary.17. I have a lead, so I'll talk with the Next.js team to confirm if it's a bug there, but I think it is very likely.
@joaogarin it's hard to say anything without a reproduction. If you think this issue is unrelated, I suggest opening a separate one with your repo to keep issues focused. :pray:
I'm having the same problem too.
An update here, we've identified the issue in Next.js and are working on a fix. This should only affect local development, deployments to eg.: Vercel should work fine!
Ran into this as well where it worked on Vercel but not locally. Also did not work on our Docker-ized production deployment to AWS. Cheers to all for the quick response.
This issue seems to be exacerbated by using the wrong Node version. I had to downgrade to next 12.2.2 and make sure I'm using Node v14.
(This is for standalone deployments in docker)
This issue seems to be exacerbated by using the wrong Node version. I had to downgrade to next 12.2.2 and make sure I'm using Node v14.
Next v12.2.2 works for me with Node v16.16.0 and i was seemingly lucky not to require a lower Node version. With Next v12.2.3 I have the issues described in the thread.
v12.2.2 doens't seem to work for me. This is only when using the custom pages. So, I create a custom layout (just copied from docs). With the login form supplied on the api routes, I am fine, and I am able to log in.
Next 12.2.0 next-auth 4.10.2 working in local but not in Vercel. token returns null
I debugged it into next auth code. The following error is thrown from jose:
JWTInvalid: JWT Claims Set must be a top-level JSON object
at __WEBPACK_DEFAULT_EXPORT__ (webpack-internal:///(middleware)/./node_modules/jose/dist/browser/lib/jwt_claims_set.js:39:15)
at jwtDecrypt (webpack-internal:///(middleware)/./node_modules/jose/dist/browser/jwt/decrypt.js:13:87)
at async decode (webpack-internal:///(middleware)/./node_modules/next-auth/jwt/index.js:64:7)
at async getToken (webpack-internal:///(middleware)/./node_modules/next-auth/jwt/index.js:104:12)
at async handleMiddleware (webpack-internal:///(middleware)/./node_modules/next-auth/next/middleware.js:37:17)
at async eval (webpack-internal:///(middleware)/./node_modules/next-auth/next/middleware.js:70:29)
at async adapter (webpack-internal:///(middleware)/./node_modules/next/dist/server/web/adapter.js:61:20)
at async /Users/sean/dev/proprate-ui/propsite/node_modules/next/dist/server/web/sandbox/sandbox.js:43:16
at async DevServer.runMiddleware (/Users/sean/dev/proprate-ui/propsite/node_modules/next/dist/server/next-server.js:766:26)
at async DevServer.runMiddleware (/Users/sean/dev/proprate-ui/propsite/node_modules/next/dist/server/dev/next-dev-server.js:446:28) {code: 'ERR_JWT_INVALID', name: 'JWTInvalid', stack: 'JWTInvalid: JWT Claims Set must be a top-leve…xt/dist/server/dev/next-dev-server.js:446:28)', message: 'JWT Claims Set must be a top-level JSON object'}
and catched here and null is returned: https://github.com/nextauthjs/next-auth/blob/main/packages/next-auth/src/jwt/index.ts#L115`
No idea what changed in next that this happened. The error is thrown when the payload is decrypted. But the secret and derived encryption key are the same. The token that is sent from the client is the same as the one received on the server. So that is pretty strange.
Maybe the encryption is the problem? idk ^^
If this is an upstream issue @balazsorban44, is there an issue we can track on their end?
Next 12.2.0 next-auth 4.10.2 working in local but not in Vercel. token returns null
Same here; everything works fine locally but not in Vercel.
Hmm. @ThangHuuVu might be right. I am able to reproduce this starting with
12.2.3-canary.17
, so something might have happened in vercel/[email protected]. I have a lead, so I'll talk with the Next.js team to confirm if it's a bug there, but I think it is very likely.@joaogarin it's hard to say anything without a reproduction. If you think this issue is unrelated, I suggest opening a separate one with your repo to keep issues focused. 🙏
Did you manage to figure anything out talking to the Next.js team?
Did you manage to figure anything out talking to the Next.js team?
Yes, you missed the response over here: https://github.com/nextauthjs/next-auth/issues/5008#issuecomment-1193772472
@ChristianIvicevic thank you! Do you know if that is tracked to an issue from the Next.js team where we can get updates?
Currently working for me, local & Vercel, with the following versions:
node.js: 16.16.0
npm: 8.11.0
next: 12.2.2
- I downgraded from 12.2.3 because it was hitting the middleware and going straight back to login, throwing an infinite loop.
next-auth: 4.10.3
nvm-windows: 1.1.9
- this isn't required, but figured I'd mention it as it's part of my local set up for switching between node versions.
middleware.ts
export { default } from "next-auth/middleware"
export const config = { matcher: ["/account/:path*"] }
I have a lead, so I'll talk with the Next.js team to confirm if it's a bug there, but I think it is very likely
@balazsorban44 do you have any news regarding this?
~Also, I'm not sure if the following is related, but it could be~(EDIT: see below). I'm having weird tokens stored in the session-token cookie. An example would be:
'eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0..hbi46D8cv-pntnso.zNkRIEJQXfNG18nVcPHFqegPdUFGF6nK-wCV8P090WIa-CYyBCEuysDTcsRT7RcywO8BpXeFDPTHq72w-l41JljcCWfSdopUh1dHwwcJu-jlWWHx55wgY1OgkbWpis9meZlDEGJg5yrE63TWqqFYKBKFiIAgusTVe1zMoa3IL8DafE1iHyRq1UYFqaDA5rwGM1NavQtf4hb9oSmU6k8VSHlCI-U7G_aiiaxhfcVmprqbPR13mgJgeW4fP-YXhVbijWXuUNk6uZ1DQhgIveD2onkAz6L-BY8m5IvYVtszlLm1we9ykeII-RWtUL_aXA.BgbSBMKPSoYmJKmQBxrieQ'
According to jwt.io decoder the body is invalid JSON, which is the same reason the _decode
method gives when returning null
.
I've been writing the main parts of my debugging in the discussion https://github.com/nextauthjs/next-auth/discussions/5074
EDIT: Nevermind the weird token. Everything seems to work using Next 12.2.2, and the new token still shows up as broken in jwt.io. For reference, the new token I get is:
eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0..-8J1SqgUtn2YiA23.j28fj0YwXhnAqD6oNsVhZVg8YqOfPevHNRnbnowWQAQX5WZ8onl4cEI7BgzqiJgzqpea0ITnUQ-8aD3hCyEFh5KP5OqXaQCtjEhtXp-__cloT6Sl3sTLXmp44PVn9fh_HiB3zr5kR7AcuyTpXyxDVGsTox2vJL2jB-hce5Ph5yvehh9KUIcw44bok4QarZLM3xz8Bv3XcQ4V6u9eMVi8X8ywiX_ra1g00xJnPeMUAmNFCQ0YBwE3Rc48YahqlQcJCyS3wFY5qh63nbS7VR_E33Ykc3yvX7wt5aAyLSK6ZitOB2cLK8gu-F_qEsLT7w.-E835xJo99aZc_qSsE-iQg
The problem is probably the fact that now Next.js is loading jose
browser bundle inside middleware instead of the Node one
I'm getting an infinite redirect using the basic usage guidance.
Dependencies
"dependencies": {
"@next-auth/prisma-adapter": "1.0.4",
"@prisma/client": "4.1.1",
"next": "12.2.2",
"next-auth": "4.10.3",
"react": "18.2.0",
"react-dom": "18.2.0"
}
Environment
System:
OS: macOS 12.5
CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
Memory: 118.29 MB / 16.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.15.1 - ~/.nvm/versions/node/v16.15.1/bin/node
Yarn: 1.22.19 - ~/.nvm/versions/node/v16.15.1/bin/yarn
npm: 8.11.0 - ~/.nvm/versions/node/v16.15.1/bin/npm
Browsers:
Chrome: 103.0.5060.134
Safari: 15.6
npmPackages:
next: 12.2.2 => 12.2.2
next-auth: 4.10.3 => 4.10.3
react: 18.2.0 => 18.2.0
middleware.ts
export { default } from 'next-auth/middleware';
Ran into this as well where it worked on Vercel but not locally. Also did not work on our Docker-ized production deployment to AWS. Cheers to all for the quick response.
Had a similar issue with Dockerized deployment to AWS, I had to downgrade to [email protected]
w/ [email protected]
. I was using [email protected]
when I had the issue.
This issue is affecting Mac and Windows I think, because in another computer running linux it works fine, very odd Edit: if you're using windows, node v16.16 doesn't seem to work, but if you use v18.7 it works I'm using "next": "^12.2.3", "next-auth": "^4.10.2", on Windows 11 Pro x64 22000
This issue is affecting Mac and Windows I think, because in another computer running linux it works fine, very odd Edit: if you're using windows, node v16.16 doesn't seem to work, but if you use v18.7 it works I'm using "next": "^12.2.3", "next-auth": "^4.10.2", on Windows 11 Pro x64 22000
I am not sure, I have this issue with "next": "^12.2.3", "next-auth": "^4.10.3", on Linux
Works like a charm by downgrading next to "12.2.2"
I found the problem to be an injected polyfill of TextDecoder
that always returns ''
, i didn't manage to reproduce the error in a smaller repro tho
The bug is in Next.js edge runtime code, next auth cannot do anything to fix it
Is that package in next-auth or next? Did you find a way around it?
On Aug 7, 2022, at 10:22 AM, Tommaso De Rossi @.***> wrote:
I found the problem to be an injected polyfill of TextDecoder that always returns '', i didn't manage to reproduce the error in a smaller repro tho
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.
Update, a fix is coming to next
https://github.com/vercel/next.js/pull/39450
Update, a fix is coming to
next
vercel/next.js#39450
in which version, it'll be solved? @balazsorban44
Same here : "next": "^12.2.4", "next-auth": "^4.10.3", MacOS 12.5
I'm having this issue on localhost. Token returns null. Downgrading next to 12.2.2 fixed it.
After I wasted my entire day yesterday because of this null token issue, I wanted to share my working solution in case it helps someone. It must be located on the same level with pages folder. NextJS removed support for using multiple middleware files (Next Auth documentation is outdated) , so everything must be handled in single middleware.ts :
import { getToken } from "next-auth/jwt";
import { withAuth } from "next-auth/middleware"
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
export default withAuth(
async function middleware(req: NextRequest) {
const token = await getToken({ req })
const stwm = req.nextUrl.pathname;
if (
stwm.startsWith('/sign-in') ||
stwm.startsWith('/sign-up') ||
stwm.startsWith('/forgot-password')) {
if (token?.email) {
return NextResponse.redirect(new URL('/dashboard', req.url))
}
}
return NextResponse.next();
},
{
callbacks: {
authorized: ({ token, req }) => {
const stw = req.nextUrl.pathname;
if (stw.startsWith('/dashboard')) {
if (!token?.email) {
return false;
}
}
return true
},
},
}
)
export const config = { matcher: ["/sign-in", "/sign-up", "/forgot-password", "/dashboard/:path*"] }
-
System:
OS: Linux 5.18 Debian GNU/Linux 10 (buster) 10 (buster) CPU: (8) x64 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz Memory: 3.12 GB / 7.42 GB Container: Yes Shell: 5.0.3 - /bin/bash
-
Binaries:
Node: 16.16.0 - /usr/local/bin/node Yarn: 1.22.19 - /usr/local/bin/yarn npm: 8.11.0 - /usr/local/bin/npm
-
npmPackages:
next: 12.2.2 => 12.2.2 next-auth: 4.10.3 => 4.10.3 react: 18.2.0 => 18.2.0
i'm trying to downgrade version next to 12.2.2 but function getToken still return null
System: OS: Linux 5.18 Debian GNU/Linux 10 (buster) 10 (buster) CPU: (8) x64 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz Memory: 3.12 GB / 7.42 GB Container: Yes Shell: 5.0.3 - /bin/bash
Binaries: Node: 16.16.0 - /usr/local/bin/node Yarn: 1.22.19 - /usr/local/bin/yarn npm: 8.11.0 - /usr/local/bin/npm
npmPackages: next: 12.2.2 => 12.2.2 next-auth: 4.10.3 => 4.10.3 react: 18.2.0 => 18.2.0
i'm trying to downgrade version next to 12.2.2 but function getToken still return null
Same here, I am new to nodeJS, next etc.. I come from the Java world so I know what I am doing but I've been pulling my hair trying to resolve this and downgrading doesn't solve the issue. I made a simple reproducer but nothing seems to work. Although the token is not null in the jwt callback of [...nextauth].js