Adding options to define `NEXTAUTH_URL` not via env vars

[grikomsn]

Summary of proposed feature Adding options to define NEXTAUTH_URL not via environment variables but via server handler creation parameters or client default parameters.

Purpose of proposed feature Allow custom and dynamic NEXTAUTH_URL value assignment via function parameters instead of environment variables, where in some cases cannot set environment variables or requires dynamic assignment.

Detail about proposed feature Some edge cases (especially Vercel multi-domain deployments) requires different values for NEXTAUTH_URL (e.g. example.com and staging.example.com), but since NEXTAUTH_URL needs to be defined via environment variable and the value retrieval is mostly hardcoded inside next-auth, currently there is no way to use different values.

Potential problems If adding a way to define NEXTAUTH_URL but still keep the option to define via environment variables, possible issues would be changing how assigning and using the default parameters work. Notable lines:

https://github.com/nextauthjs/next-auth/blob/0987f72acbbe655aedfcd8b9b6d18acf59207329/src/client/index.js#L25-L26

https://github.com/nextauthjs/next-auth/blob/0987f72acbbe655aedfcd8b9b6d18acf59207329/src/client/index.js#L313-L314

https://github.com/nextauthjs/next-auth/blob/0987f72acbbe655aedfcd8b9b6d18acf59207329/src/lib/jwt.js#L105-L108

https://github.com/nextauthjs/next-auth/blob/0987f72acbbe655aedfcd8b9b6d18acf59207329/src/server/index.js#L16-L20

https://github.com/nextauthjs/next-auth/blob/0987f72acbbe655aedfcd8b9b6d18acf59207329/src/server/index.js#L50

Describe any alternatives you've considered Some alternative approaches would be either automagically detect the URL, or use Next.js runtime configuration to store various default values including NEXTAUTH_URL (probably not the best approach since it's incompatible with automatic static optimization).

Additional context This proposal issue was created because I am currently developing a Next.js based application which requires multiple subdomain and deployed using Vercel and we can't set dynamic env vars for NEXTAUTH_URL for different branches on Vercel.

Another context is that I've tried recreating the next-auth codebase using tsdx but since there's Docusaurus and various sources that I'm not familiar with, I didn't continue working on the rewrite (for now).

Please indicate if you are willing and able to help implement the proposed feature.

I am willing to help in any way, unless if https://github.com/nextauthjs/next-auth/pull/516#issuecomment-763126791 is on the way, I can help rewrite some TypeScript stuff and include this proposed feature if considered.

[grikomsn]

Submitted #1168 which proposed defining NEXTAUTH_URL via Next.js runtime configuration.

[iaincollins]

It's currently an environment variable to simplify configuration.

This is so that it only needs to be defined in one place, which covers Server Side Rendering of pages, Client Side Rendering of pages and API routes and works across platforms (Vercel, Netlify, Heroku, AWS Lambda, inside a Docker container, etc) and that as long as it's configured everything should "just work" with as few caveats as possible.

We are interested in exploring options to move some configuration out (e.g. into a file like nextauth.config.js) but we'd want to be careful with what information we exposed from the client to the server if we did that (i.e. so that people don't inadvertently end up creating a client side bundle that included sensitive credentials for a provider and/or database).

Automatic detection and/or dynamic configuration isn't as helpful as people often suppose as the majority of OAuth providers require specific callback URLs to be configured for use. In some cases, like GitHub, only a single host is valid for a given set of credentials.

Different CLIENT/SECRET OAuth credentials should be used for development instances vs live, meaning setting NEXTAUTH_URL as well doesn't make much of a difference as to what's required. Setting up a pre-live site like staging.example.com (and, optionally, having it wired to a Git branch like staging) is a straightforward one-time thing.

The problem it addresses - improving support for testing on pull request environments - which typically cannot be used with OAuth providers, for reasons not to do with NextAuth.js - is something we've discussed though and would like to provide some sort of support for, and have ideas around.

It would be easier to do something as a SAAS solution, I think we could create something very slick there and would very much like to explore that in future. Thee isn't a way to support OAuth with dynamic hostnames without running some sort of service.

Currently, given the limitations of OAuth providers, having a conditional switch in [...nextauth].js to configure an Email provider on is one way of providing a sign in experience on test instances with dynamic hostnames. The fallback to VERCEL_URL is explicitly support this sort of flow. Hard coding some account details in a Credentials provider (that is only configured on those instances) is also an option that may work for some folks.

[dhalbrook]

I realize our use case is probably outside the norm, but we are building a multi-tenant front end mapped to multiple hostnames, and were planning on having a provider registered for each tenant (so per callback URL).

[stale[bot]]

Hi there! It looks like this issue hasn't had any activity for a while. It will be closed if no further activity occurs. If you think your issue is still relevant, feel free to comment on it to keep it open. (Read more at #912) Thanks!

[stale[bot]]

Hi there! It looks like this issue hasn't had any activity for a while. To keep things tidy, I am going to close this issue for now. If you think your issue is still relevant, just leave a comment and I will reopen it. (Read more at #912) Thanks!

[ThibaultJanBeyer]

Hi there, thanks for next-auth btw. it’s awesome :) Can this please just be a runtime config? What if I use ngrok tunneling and get another address every time? How can I update the env variable dynamically then? Seems like overcomplicating things, why not be able to optionally pass that variable in all places where it is needed to avoid using .env variables? Thank you!