experimental getServerSession sometimes doesn't use NEXTAUTH_SECRET env variable

Description 🐜

calling the experimental getServerSession() (e.g. within a nextjs api handler) randomly fails to initialize the JWT secret from the environment variable NEXTAUTH_SECRET. This causes the JWT decryption to fail, unless secret is explicitly configured.

[next-auth][warn][NO_SECRET]
https://next-auth.js.org/warnings#no_secret
[next-auth][error][JWT_SESSION_ERROR]
https://next-auth.js.org/errors#jwt_session_error decryption operation failed {
  message: 'decryption operation failed',
  stack: 'JWEDecryptionFailed: decryption operation failed\n' +
    '    at gcmDecrypt (D:\\next-auth-example\\node_modules\\jose\\dist\\node\\cjs\\runtime\\decrypt.js:67:15)\n' +
    '    at decrypt (D:\\next-auth-example\\node_modules\\jose\\dist\\node\\cjs\\runtime\\decrypt.js:92:20)\n' +
    '    at flattenedDecrypt (D:\\next-auth-example\\node_modules\\jose\\dist\\node\\cjs\\jwe\\flattened\\decrypt.js:119:52)\n' +
    '    at async compactDecrypt (D:\\next-auth-example\\node_modules\\jose\\dist\\node\\cjs\\jwe\\compact\\decrypt.js:18:23)\n' +
    '    at async jwtDecrypt (D:\\next-auth-example\\node_modules\\jose\\dist\\node\\cjs\\jwt\\decrypt.js:8:23)\n' +
    '    at async Object.decode (D:\\next-auth-example\\node_modules\\next-auth\\jwt\\index.js:64:7)\n' +
    '    at async Object.session (D:\\next-auth-example\\node_modules\\next-auth\\core\\routes\\session.js:41:28)\n' +
    '    at async NextAuthHandler (D:\\next-auth-example\\node_modules\\next-auth\\core\\index.js:96:27)\n' +
    '    at async getServerSession (D:\\next-auth-example\\node_modules\\next-auth\\next\\index.js:67:19)\n' +
    '    at async __WEBPACK_DEFAULT_EXPORT__ (webpack-internal:///(api)/./pages/api/examples/session.ts:12:21)',
  name: 'JWEDecryptionFailed'

In my testing on CodeSandBox, the success rate varied widely between sandbox restarts, either working most of the time or failing most of the time.

As a workaround, adding secret: process.env.NEXTAUTH_SECRET to my nextauth configuration consistently fixed the issue.

Is this a bug in your own project?

No

How to reproduce ☕️

1. clone https://github.com/JTBrinkmann/next-auth-example (already includes a .env.local with a secret)
2. run yarn install and yarn run dev (or npm equivalent)
3. log in on the page
4. go to the API page
5. navigate around the site
6. confirm that the API calls sometimes fail (codeblocks show null)
7. pages using getSession() should work
8. add secret: process.env.NEXTAUTH_SECRET, to next-auth.config.ts
9. repeat step 5., confirm that the API calls work (codeblocks show JSON data)

Alternatively, https://d7git.sse.codesandbox.io/ can be used for testing; but when you fork you might need to adjust the URL in the .env.local to your fork’s domain.

Screenshots / Logs 📽

refreshing the page shows inconsistent results

Environment 🖥

on my system:

  System:
    OS: Windows 10 10.0.17763
    CPU: (6) x64 Intel(R) Core(TM) i5-9600 CPU @ 3.10GHz
    Memory: 4.37 GB / 15.78 GB
  Binaries:
    Node: 16.13.2 - ~\scoop\apps\nodejs-lts\current\node.EXE
    Yarn: 1.22.17 - ~\scoop\apps\yarn\current\bin\yarn.CMD
    npm: 8.1.2 - ~\scoop\apps\nodejs-lts\current\npm.CMD
  Browsers:
    Edge: Spartan, Chromium, ChromiumDev
    Internet Explorer: 11.0.17763.2145
  npmPackages:
    next: ^12.0.11-canary.4 => 12.0.11-canary.9
    next-auth: latest => 4.2.1
    react: ^17.0.2 => 17.0.2

On CodeSandBox:

  System:
    OS: Linux 5.4 Debian GNU/Linux 10 (buster) 10(buster)
    CPU: (16) x64 Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
    Memory: 1.79 GB / 62.73 GB
    Container: Yes
    Shell: 5.0.3 - /bin/bash
  Binaries:
    Node: 14.18.1 - ~/.nvm/versions/node/v14.18.1/bin/node
    Yarn: 1.22.17 - ~/.nvm/versions/node/v14.18.1/bin/yarn
    npm: 6.14.15 - ~/.nvm/versions/node/v14.18.1/bin/npm
  npmPackages:
    next: ^12.0.11-canary.4 => 12.0.11-canary.9
    next-auth: latest => 4.2.1
    react: ^17.0.2 => 17.0.2

Contributing 🙌🏽

No, I am afraid I cannot help regarding this

[ifightcrime]

I’m running into this as well on Vercel

[JTBrinkmann]

The problem isn’t the env variable being unavailable, but that NextAuth doesn’t consider it. While getServerSession prints the warning, process.env.NEXTAUTH_SECRET is correct 100% of the time (tested with breakpoints, and with console.log(process.env.NEXTAUTH_SECRET) right before getServerSession()). Looking at the repo, NextAuth apparently initializes the config at some point, which has a sideeffect of defaulting the secret to NEXTAUTH_SECRET. When calling getServerSession, that initialization isn’t guaranteed to have happened. The cases where it does work is probably because of a race condition, where some other function on that thread runs the initialisation and thereby modifies the configuration object.