Need to set NEXTAUTH_URL dynamically as an Option for multi-domain/multi-tenant use

[SharadKumar]

Your question
How to dynamically work with Passwordless/Email auth, without setting NEXTAUTH_URL.

What are you trying to do
I am working on a use-case where NEXTAUTH_URL is not fixed at deploy-time or build-time, but run-time, for a multi-domain (single codebase) scenario. This is to have Email passwordless only.

I have had good success with next-auth other providers for usual scenarios, and absolutely love the simplicity.

Feedback
I tried to browse around the code to get a sense of dependency of the deploy-time NEXTAUTH_URL, and it seems that it is use only to define the Url for sendVerificationRequest. If there was a way to pass it as an option, it would do it.

Please advise, whats the best approach.

• Found the documentation helpful
• Found documentation but was incomplete
• Could not find relevant documentation
• Found the example project helpful
• Did not find the example project helpful

[SharadKumar]

Server has a todo flagged:

next-auth/src/server/index.js

Lines 47 to 50 in 12a5d6b

	// @todo refactor all existing references to site, baseUrl and basePath
	const parsedUrl = parseUrl(process.env.NEXTAUTH_URL || process.env.VERCEL_URL)
	const baseUrl = parsedUrl.baseUrl
	const basePath = parsedUrl.basePath

JWT. GetToken can be custom though:

next-auth/src/lib/jwt.js

Lines 94 to 103 in 8115a7c

	const getToken = async (args) => {
	const {
	req,
	// Use secure prefix for cookie name, unless URL is NEXTAUTH_URL is http://
	// or not set (e.g. development or test instance) case use unprefixed name
	secureCookie = !(!process.env.NEXTAUTH_URL || process.env.NEXTAUTH_URL.startsWith('http://')),
	cookieName = (secureCookie) ? '__Secure-next-auth.session-token' : 'next-auth.session-token',
	raw = false
	} = args
	if (!req) throw new Error('Must pass `req` to JWT getToken()')

And, for the client:

next-auth/src/client/index.js

Lines 24 to 26 in 8115a7c

	const __NEXTAUTH = {
	baseUrl: parseUrl(process.env.NEXTAUTH_URL || process.env.VERCEL_URL).baseUrl,
	basePath: parseUrl(process.env.NEXTAUTH_URL).basePath,

These are the references I found. @iaincollins I can try to fork and attempt a hack on my side, since I really need to solve this. If you can advise how to go about it, it would be awesome. It seems you intend to refine/refactor this at some point, as stated above. Above three are the only references I found.

Any help is really appreciated.

[SharadKumar]

Okay, so I managed to fork and make server-side work! Looking into the client side now...

I added to server:

    const { origin } = absoluteUrl(req)

    // @todo refactor all existing references to site, baseUrl and basePath
    const parsedUrl = parseUrl(process.env.NEXTAUTH_URL || origin || process.env.VERCEL_URL)

and lib/parse-url.js: (I couldn't find a way to get protocol with NextJS req object:

export const absoluteUrl = (req) => {
  var protocol = "https:"
  var host = req
    ? req.headers["x-forwarded-host"] || req.headers["host"]
    : window.location.host

  if (host.indexOf("localhost") > -1 || host.indexOf(".local") > -1) {
    protocol = "http:"
  }
  return {
    protocol: protocol,
    host: host,
    origin: protocol + "//" + host,
  }
}

[iaincollins]

Hi Sharad,

If you are seeing this error there is likely problem with your build process or how you are linking to the libraries. You'd need to post and link to the repo before we can help with that.

Regarding the wider question of supporting domains dynamically, this is something we don't support currently. I don't have an update on this I'm ready to share right now, but I hope there will be an update on this at some point in the coming weeks.

[SharadKumar]

Thanks Iain, yes I am trying to get my head around this.
I've been able to work with multiple-domains dynamically, and to do that I forked... modified server to work with origin (as above) based on current request. At the moment, my main use case is Email provider.

I also started my own Adapter, based on your prisma adapter... to support multi-tenancy in database. Pretty much everything you have as-is, plus associating users with a Business (tenant) record.

Excellent work with next-auth. So helpful.

[dhalbrook]

We really need this as well, as we have a multi-tenant Next app in the works.

It seems like you could take in a callback function in the userSuppliedOptions of server/index.js that would pass the req object in, like userSuppliedOptions.baseUrlSupplier(req), to allow everyone to specify the base URL as needed from the request (in our cases tenancy has more than one potential marker). Not sure of the best way to get the derived value to jwt.js:99 though.

[dolie]

Our application is multi-tenant as well. We also need(ed) this feature.
We decided to deploy one environment for each tenants to resolve this issue.

[ChuckJonas]

I also need this to be able to properly setup salesforce as a custom oAuth2 provider:

https://${instanceUrl}.salesforce.com/services/oauth2/token

There are cases where the user will need to specify their "subdomain" in order to be able to login.

[skilesare]

I've tried to address this here: skilesare@86ea3de

It may need some changes....and I only really focused on the session call back because I needed to get some data based on the domain in the session, but the pattern should be easy to follow for the other callbacks. Basically the request (req) just needs to be passed to these callbacks so that you can key in on the domain/sub domain. The other potential gotcha is the http vs https so if anyone has a suggestion for that, let me know.

If any one wants to walk me through how to get this set up so that it can eventually be pulled in, let me know as well...haven't contributed to projects this big before and don't want to step on any toes.

[trollr]

Our application is multi-tenant as well. We also need(ed) this feature. I would like to be able to simply set the redirect_url in the provider options

[ramiel]

One good reason to think to support multi-tenant is that nex-auth is likely to be deployed on vercel. On vercel each deployment has several domains (a lot more if the user defined aliases). Since this is a project for next.js, supporting Vercel looks natural to me.

[balazsorban44]

To anyone reading this, please stop +1 issues, it is really not helpful, and creates noise. 😕

If you have nothing constructive to add, do click "👍" on the original comment instead.

[mauron85]

The problem with AUTH_TRUST_HOST is that it doesn't respect basePath option of nextjs. And it's because parse-url uses defaultUrl in when AUTH_TRUST_HOST is true. There should either option eg. AUTH_TRUST_PATHNAME or next-auth should parse NEXTAUTH_URL for the basePath.

next-auth/packages/core/src/lib/utils/parse-url.ts

Line 16 in 465e882

const defaultUrl = new URL("http://localhost:3000/api/auth")

[wildfrontend]

it is big problem , because NEXTAUTH_URL is for client side url, and client side url could be multi domain, it would be cause wrong domain redirect , so baseUrl should not be static variable , or maybe set a option in authOptions to change baseUrl

next-auth/packages/next-auth/src/lib/client.ts

Line 160 in cf9712e

export function apiBaseUrl(__NEXTAUTH: AuthClientConfig) {

https://github.com/nextauthjs/next-auth/blob/cf9712e784a9075622ce18bdb586f86223073226/packages/next-auth/src/react.tsx#L56C26-L56C26

@balazsorban44

[mauron85]

@wildfrontend I see there is quite big refactor in v5 regarding this. I was referring to v4. The parse-url is gone and instead I see:

next-auth/packages/next-auth/src/lib/env.ts

Line 43 in cf9712e

export function reqWithEnvUrl(req: NextRequest): NextRequest {

Also I was talking about backend api/auth/providers not respecting basePath option and generating callback and redirect url without basePath.

If your issue is on client side. You can get basePath from runtime config in _app.tsx:

        import getConfig from 'next/config';

        export default function MyApp({ Component, pageProps: { session, ...pageProps } } {
          const { publicRuntimeConfig: c } = getConfig();
  
          return (
		  <SessionProvider
			  session={session}
			  basePath={`${c.basePath}/api/auth`}
		  >{...}
		  </SessionProvider>
           );
       }

in next.config.js you can set basePath from env param and also expose same value for runtime config (used in _app.tsx - as above)

const nextConfig = {
	basePath: process.env.NEXT_RT_BASEPATH,
	publicRuntimeConfig: {
		basePath: process.env.NEXT_RT_BASEPATH ?? '',
	}
}

[mauron85]

Very ugly workaround for v4 basePath issue when AUTH_TRUST_HOST is true:

Since req.origin is set by toInternalRequest function (detectOrigin) reading x-forwarded-host header and then req.origin is used in parseUrl, but since x-forwarded-host doesn't contain any paths, we need to add it, so parseUrl respects basePath.

pages\api\auth[...nextauth].ts

export default async function auth(req: NextApiRequest, res: NextApiResponse) {
	// Info: Workaround for providers callback signinUrl and callbackUrl not including basePath
	if (req.headers['x-forwarded-host']) {
		req.headers['x-forwarded-host'] = `${req.headers['x-forwarded-host']}${process.env.NEXT_RT_BASEPATH}/api/auth`;
	}

	return await NextAuth(req, res, { ...options });
}

[ZainXalid]

Hey guys, (@mauron85, @wildfrontend)
What do you think about this approach for NextJS 13? Will it work for both sub and custom domains?

https://www.skcript.com/blog/how-to-build-multi-tenant-auth-nextjs

[brunoalano]

Any workaround for next-auth@v5?

[aman-godara]

1. setting env variable AUTH_TRUST_HOST=true didn't work
2. dynamically setting process.env.NEXTAUTH_URL (with advanced initialization) worked but isn't thread safe (you can get its code from here: Dynamic NEXTAUTH_URL #969)
3. custom solutions built by @Robert-OP & @skilesare are too old
4. use next-auth on a subdomain as a separated authentication service #1299 & How to manage multiple domains with NextAuth.js? #4022 are hard to implement

[osiegmar]

@balazsorban44 Given the fact that this issue is by far the most upvoted one and was opened three years ago, I would like to kindly ask if it is possible to get a bit more attention?

[basememara]

Vercel published a multi-tenant Platforms Starter Kit using Next.js and NextAuth v4. Seems like it's hardcoded to Vercel hosting though: https://vercel.com/templates/next.js/platforms-starter-kit (repo)

[LoganArnett]

Same question on the v5 front, trying to accomplish this and the NextAuth default export no longer accepts the req, res

[ZainXalid]

Short Answer: It's not supported.

Some devs may find a work around but if you don't know what you're doing then please look for an alternative option. I wasted a lot of time looking for it and, in the end, had to look for an alternative option.

Clerk Auth supports it otherwise go for a custom auth solution.

[do4Mother]

i solve this issue by adding process.env.AUTH_TRUST_HOST = true and process.env.VERCEL = true

edit SessionProvider and add baseUrl and basePath (baseURL + '/api/auth')

to get baseUrl you can use this code

  const getHeader = headers();
  const protocol = getHeader.get("x-forwarded-proto") ?? "";
  const host = getHeader.get("X-Forwarded-Host") ?? "";

[ronfor]

A solution for v4, for the benefit of others and to get feedback.

My requirement is to support multiple domains from one Nextjs build (thirteen different county domains). For each domain I need separate NextAuth Provider configuration because each domain will authenticate with different providers.

For example, the configuration I will basis this on will look a little like:

const countrySettings = {
  FR: {
    host: 'https://mywebsite.fr',
    provider: 'mywebsite-fr.auth0.com',
    clientId: 'fr-client-id',
    secret: '123456789',
  },
  IT: {
    host: 'https://mywebsite.it',
    provider: 'mywebsite-it.auth0.com',
    clientId: 'it-client-id',
    secret: '987654321',
  },
  // ... 11 more ...
}

As I have different domains I have not set the NEXTAUTH_URL var.

I dynamically generate the AuthOptions based upon the incoming host and pass to NextAuth. When loading the options the host is checked against known hosts (whitelist).

[...nextauth]/route.ts

function auth(req, res) {
  const host = req.headers.get('host')
  const country = countryFromHost(host)
  // authOptions dynamically selected for the given request
  return NextAuth(req, res, authOptions(country))
}

I'm using Auth0 as the authentication Provider, this is the following Provider definition (reduced for brevity) returned dynamically:

const authOptions : (string) => NextAuthOptions = memoize((country) => 
{
providers: [
  Auth0Provider({
      clientId: countrySettings[country].cientId,
      clientSecret:  countrySettings[country].secret,
      issuer: countrySettings[country].provider,
      httpOptions: {
        headers: {
          // Auth0 specific - ensure correct validation result due to a comparison with the callback URL
          origin: countrySettings[country].host
        }
      },
      authorization: {
        params: {
          prompt: 'login',
          redirect_uri: `countrySettings[country].host/api/auth/callback/auth0`
        },
      },
    })
  ],
  callbacks: {
    redirect() {
      return countrySettings[country].host
    }
  }
)

Finally, I had to set AUTH_TRUST_HOST to true so that NextAuth does not default to localhost in the callback domain check.

import { strict as assert } from 'node:assert'

assert.equal(process.env.AUTH_TRUST_HOST, 'true')
assert.equal(process.env.NEXTAUTH_HOST, undefined)

Any feedback or potential issues with this approach are appreciated!

[agsola]

I still don't understand how little support for this is given from Vercel.

[ELF1sH]

We faced quite the same problem. Our project is hosted on several subdomains:

1. domain.com
2. subdomain1.domain.com
3. subdomain2.domain.com
4. ...
5. subdomain9.domain.com

Authorization flow works perfectly fine on localhost because it is a single domain name. After hosting the project on the remote server, next-auth, while being opened on the subdomain1.domain.com, right after successful login tries to redirect to http://domain.com since that is the url specified in the NEXTAUTH_URL env variable. As a result, it displays the error page with a note Try signing in with a different account. This means that we need to somehow dynamically set the env variable NEXTAUTH_URL. We use next-auth 4.24.7, Keycloak Provider and next 14.0.3. Although the following solution should apply to different types of providers and next-auth's versions.

Step 1.
Get rid of the NEXTAUTH_URL env variable. Since we are using Keycloak provider, the only authentication-related env variables we have are KEYCLOAK_CLIENT_ID, KEYCLOAK_CLIENT_SECRET, KEYCLOAK_ISSUER and NEXTAUTH_SECRET.

Step 2.
Rewrite the next-auth api handler. The official next-auth documentation suggests using the following approach (applied to next.js with the app directory):
touch app/api/auth/[...nextauth]/route.ts and paste the following code there:

import NextAuth from "next-auth/next";

const handler = NextAuth(authOptions);

export { handler as GET, handler as POST };

There is a huge disadvantage to this approach. You cannot customize the handler itself. There is no function body where you can insert your own custom code. Therefore, we suggest rewriting the file as follows:

import { NextApiRequest, NextApiResponse } from 'next';
import { NextRequest, NextResponse } from 'next/server';
import NextAuth from 'next-auth';

async function auth(req: NextRequest, res: NextResponse) {
  return await NextAuth(req as unknown as NextApiRequest, res as unknown as NextApiResponse, authOptions);
}

export { auth as GET, auth as POST };

It works exactly the same while being more flexible. Every auth request goes through this 'middleware'. Here we're going to dynamically set the NEXTAUTH_URL env variable depending on the host and protocol of the request headers

async function auth(req: NextRequest, res: NextResponse) {
  const protocol = req.headers.get('x-forwarded-proto');
  const host = req.headers.get('host');

  process.env.NEXTAUTH_URL = `${protocol}://${host}/api/auth`;

  return await NextAuth(req as unknown as NextApiRequest, res as unknown as NextApiResponse, authOptions);
}

export { auth as GET, auth as POST };

Step 3.
Specify the redirect callback in the authOptions.

callbacks: {
  // ...
  // your callbacks here, such as `jwt` and `session`
  // ...
  async redirect({ url }) {
    return url;
  },
}

The first url argument is the url received from the client side of the application. In other words, this is the url that you pass as the callbackUrl argument when calling the signIn function.

await signIn('keycloak', { redirect: false, callbackUrl: window.location.origin });

Step 4.
Make sure you pass window.location.origin as the callbackUrl every time you invoke signIn or signOut functions.

After completing the previous steps, your authorization flow should work fine. If you're concerned about the rest of the code, you can follow these tutorials: part1 and part2.

However, you may encounter a bug: when different users from different computers log in at the same time, their redirect URLs after successful login may get mixed up, and, as a result, users may end up in someone else's subdomain. Because of that users see Try signing in with a different account error page once again. In order to avoid this behavior, complete the upcoming step.

Step 5.
Your SessionProvider should look like this.

export default function AuthSessionProvider(props: PropsWithChildren) {
  const { children } = props;

  return (
    <SessionProvider refetchInterval={REFETCH_INTERVAL} refetchOnWindowFocus>
      {children}
    </SessionProvider>
  );
}

Avoid using basePath prop of the SessionProvider at any cost. It took us several weeks to find out that this prop was causing the bug with incorrect redirects after successful logins.