RFC: Autogenerate NEXTAUTH_SECRET env var for users as a part of the build process?

[ndom91]

Summary of proposed feature

We want to make setting up NextAuth.js as simple as possible. In that vain, some providers (like Vercel and Netlify) already automatically set the NEXTAUTH_URL environment variable for us when they detect a project using next-auth.

That leaves only the NEXTAUTH_SECRET environment variable left for the user to manually set.

We did some experimenting, and discovered that we could set this value behind the scenes during build-time for the user. Eliminating the need for any initial environment variables for NextAuth.js! (Other than of course any OAuth providers, database connection strings, etc. that you choose to use)

So what do you think? Would this be helpful for you? Any thoughts, comments, questions or concerns are very welcome!

Detail about proposed feature

I have two POC's currently deployed, one at Vercel and one at Netlify, both based off of the following repository - ndom91/next-auth-example-sign-inpage.

• Vercel Example: https://next-auth-example-sign-in-page.vercel.app/auth/signin
• Netlify Example: https://next-auth-example-sign-in.netlify.app/auth/signin

These both work via the create-env.js node script which is currently prepended to the build step of this example repository, but could be set to run in a postbuild step in the next-auth package, for example.

This script is relatively simple, and does the following:

1. Check if NEXTAUTH_SECRET is already set (i.e. allow user to still manually set it)
2. Check if a ./.env file exists (this is where hosting providers like Netlify / Vercel seemingly write out env variables to during build)
3. Either append to that file, or create it from scratch, with a NEXTAUTH_SECRET env var.

Open for initial create-env.js contents

const { access, appendFile, writeFile } = require('fs/promises')
const { randomBytes } = require('crypto')
const { constants } = require('fs')

if (process.env.NEXTAUTH_SECRET) {
  process.exit(0)
}

(async () => {
  const randomString = randomBytes(16).toString('hex')
  try {
    await access("./.env", constants.R_OK && constants.W_OK)
    await appendFile('./.env', `\nNEXTAUTH_SECRET=${randomString}\n`)
  } catch (error) {
    await writeFile('./.env', `NEXTAUTH_SECRET=${randomString}\n`)
  }
})()

Potential problems

• Is this too hacky?

Describe any alternatives you've considered

The platforms could generate a source of entropy for apps / libraries to use during build time. Something like a set of env vars filled with 8bit, 16bit, 32bit, etc. length random character strings that could then be used during the build process would be useful for many others I'm assuming as well, not just NextAuth.js..

Additional context

Just trying to gather some community feedback! Would this be useful for you? Do you foresee any potential issues? Any suggestions to improve?

Thanks!