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.

[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

[ZainKhalidOfficial]

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.

[jeanclei]

I also use next auth, and I need each tenant to have its own separate authentication, in which a token issued in one tenant cannot be valid for another tenant, I also need the callback URLs to be dynamic, I managed to handle this by making the callback to add the tenant field in the token, and then I compare the token's tenant with the host in a middleware:

  // pages/api/auth/[...nextauth].ts
  
  import { connectToDatabase } from "@/config/mongodb"
  import type { NextApiRequest, NextApiResponse } from "next"
  import NextAuth from "next-auth"
  
  import bcrypt from "bcryptjs";
  
  import CredentialsProvider from "next-auth/providers/credentials"
  import GoogleProvider from "next-auth/providers/google"
  
  export default async function auth(req: NextApiRequest, res: NextApiResponse) {
    // Do whatever you want here, before the request is passed down to `NextAuth`
  
    const { host } = req.headers;
  
    const proto = req.headers['x-forwarded-proto'] || 'http';
  
    process.env.NEXTAUTH_URL = `${proto}://${host}`;
  
    return await NextAuth(req, res, {
      
      providers: [
        CredentialsProvider({
          name: "Credentials",
          credentials: {
            email: { label: "E-mail", type: "text", placeholder: "User" },
            password: { label: "Senha", type: "password" }
          },
          async authorize(credentials, req) {
  
            const hostHeader = req?.headers?.host;
  
            const { db } = await connectToDatabase();
            const users = db.collection("users");
            const user = await users.findOne({ email: credentials?.email.toLowerCase() });
            // console.log("headerHost", hostHeader)
            // console.log("headerUser", user.host)
            if (!user || !hostHeader) {
              throw new Error("Usuário não encontrado");
            }
            if (hostHeader !== user.host && user.host !== "all") {
              throw new Error("Usuário não encontrado");
            }
  
            if (credentials?.password) {
              const match = await bcrypt.compare(credentials?.password, user.password);
              if (!match) {
                throw new Error("Senha incorreta");
              }
            } else {
              throw new Error("Senha incorreta");
            }
            return user;
          }
        }),
        GoogleProvider({
          clientId: process.env.GOOGLE_OAUTH_ID || '',
          clientSecret: process.env.GOOGLE_OAUTH_SECRET || '',
          authorization: {
            params: {
              prompt: "consent",
              access_type: "offline",
              response_type: "code",
              
            }
          }
        })
      ],
      pages: {
        signIn: '/login'
      },
      callbacks: {
        async jwt({ token, user }) {
  
          if (user) {
            token.user = user;
            token.tenant = host;
          }
  
          return token
        },
        async session({ session, token, user }) {
  
          // Inicializa session.user se não estiver definido
          if (!session.user) {
            session.user = {};
          }
  
          session.user.tenant = token.tenant;  // Adiciona o tenant à sessão
          return session;
        },
  
        async signIn({ user, account, profile, email, credentials }) {
  
  
          if (account?.provider === "google") {
  
            const { db } = await connectToDatabase();
            const users = db.collection("users");
            const userdb = await users.findOne({ email: user.email?.toLowerCase(), host });
  
            if (!userdb) {
              console.warn("host: ", host);
              console.warn("Usuário do google não encontrado: ", user.email?.toLowerCase());
              return false;
            }
  
          }
          
  
          return true;
  
        },
  
        // async redirect({ url, baseUrl }) {
  
  
        //   baseUrl = `${proto}://${host}`;
  
        //   console.log("redirect url", url);
        //   console.log("redirect baseUrl", baseUrl);
  
        //   console.log("host in redirect:", host);
        //   // Allows relative callback URLs
        //   if (url.startsWith("/")) return `${baseUrl}${url}`
        //   // Allows callback URLs on the same origin
        //   else if (new URL(url).origin === baseUrl) return url
  
          
        //   return baseUrl
        // }
  
      }
    })
  }
  

Extend Session and JWT:

// next-auth.d.ts
import NextAuth, { DefaultSession } from 'next-auth';
import { JWT } from 'next-auth/jwt';

// Extenda o tipo de sessão
declare module 'next-auth' {
  interface Session {
    user: {
      tenant?: string;
    } & DefaultSession['user'];
  }

  interface User {
    tenant?: string;
  }
}

// Extenda o tipo de token JWT
declare module 'next-auth/jwt' {
  interface JWT {
    tenant?: string;
  }
}

Auth Middleware:

// middlewares/authMiddleware.ts

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { getToken } from 'next-auth/jwt';

const secret = process.env.NEXTAUTH_SECRET;

export async function authMiddleware(req: NextRequest) {
    const token = await getToken({ req, secret });

    if (!token) {
        console.warn('Unauthorized: no token');
        return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
    }

    if (token.tenant !== req.headers.get('host')) {
        console.warn('Unauthorized: tenant mismatch', "token:", token.tenant, "host:", req.headers.get('host'));
        return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
    }

    return NextResponse.next();
}

export const config = {
    matcher: ['/api/(?!chat|webhook|auth)(.*)'], // Defina as rotas que devem usar authMiddleware
};

Middleware:

import { NextRequest, NextResponse } from 'next/server';
import { imagesMiddleware, config as imagesConfig } from './middlewares/imagesMiddleware';
import { authMiddleware, config as authConfig } from './middlewares/authMiddleware';

export async function middleware(req: NextRequest) {
    const url = req.nextUrl.pathname;

    // Aplica imagesMiddleware apenas para rotas correspondentes
    if (imagesConfig.matcher.some(pattern => new RegExp(pattern).test(url))) {
        const response = imagesMiddleware(req);
        return response;
    }

    // Aplica authMiddleware apenas para rotas correspondentes
    if (authConfig.matcher.some(pattern => new RegExp(pattern).test(url))) {
        const response = await authMiddleware(req);
        return response;
    }

    return NextResponse.next();
}

[skulden13]

Hey everybody,

This works for me.
I've set the NEXTAUTH_URL env variable from the inside NextJS API route before NextAuth init.

const { host } = req.headers;
const protocol = !host.includes('local') ? 'https' : 'http';
process.env.NEXTAUTH_URL = `${protocol}://${host}/api/auth/`;

Full example:

import NextAuth from 'next-auth';
import KeycloakProvider from 'next-auth/providers/keycloak';

export default async function auth(req, res) {
  const { host } = req.headers;

  const protocol = !host.includes('local') ? 'https' : 'http';
  process.env.NEXTAUTH_URL = `${protocol}://${host}/api/auth/`;

  async function createProviders() {
    const keycloakConfig = {
      clientId: process.env.KEYCLOAK_CLIENT_ID,
      clientSecret: process.env.KEYCLOAK_CLIENT_SECRET,
      issuer: KEYCLOAK_ISSUER,
      realm: REALM,
    };

    return [KeycloakProvider(keycloakConfig)];
  }

  const providers = await createProviders();

  const authOptions = {
    providers,
    callbacks: {
      async session({ session, token }) {
        ...
      },
      async jwt({ token, user, account }) {
        ...
      },
    },
  };

  return NextAuth(req, res, authOptions);
}

Thanks,
Denys

[henryfitz27]

Hello @skulden13 , I am starting with next auth, could you help me with a doubt?, are you using next auth v4 or auth js?
Thank you

[skulden13]

@henryfitz27 Hi! I'm using NextAuth v4. It has all that I need.

[victor1valfr]

thank you men
after a lot of hours, it worked

[jomarl]

Is this safe if your application is not serving only a single user/host at the same time? E.g. could potentially request 2 change the environment variable before all access to it from request 1 have completed? In any other tech I've worked with this would potentially create rather hard to detect concurrency issues.

[swve]

Hey 👋🏻, if you're still struggling with this issue, here's an update :

• With NextAuth v5, the NEXTAUTH_URL (host) now is fetched from the request headers, and you no longer need to put a fixed url : https://authjs.dev/getting-started/deployment#auth_url
• They also pushed a fix for Oauth Providers when your users need to login from multiple subdomains or preview domains or completely different domains : https://authjs.dev/getting-started/deployment#securing-a-preview-deployment
• Here is guide on how to migrate to v5 : https://authjs.dev/getting-started/migrating-to-v5

I hope it fixes your issues.

[victor1valfr]

@woodwoerk Hi, this code worked for me

import type { NextApiRequest, NextApiResponse } from 'next';
import NextAuth from 'next-auth';
import GoogleProvider from 'next-auth/providers/google';

export default async function auth(req: NextApiRequest, res: NextApiResponse) {
  const host = req.headers.host;
  process.env.NEXTAUTH_URL = `https://${host}/user/api/auth/`;

  return await NextAuth(req, res, {
    providers: [
      GoogleProvider({
        clientId: process.env.NEXT_PUBLIC_GOOGLE_CLIENT_ID ?? '',
        clientSecret: process.env.GOOGLE_CLIENT_SECRET ?? '',
        idToken: true,
      }),
    ],

    callbacks: {
      jwt({ token, account }) {
        if (account) {
          token.id_token = account.id_token;
        }
        return token;
      },
      session({ session, token }) {
        if (session.user) {
          session.idToken = token.id_token;
        }
        return session;
      },
    },
  });
}

Any question let me know!

[GoldenChrysus]

@victor1valfreepik The above code is v4. They said v5. Also curious if it's thread safe. Changing a process value at runtime seems ill-advised. There are more appropriate ways to handle this even in v4.

@woodwoerk If you look at the convo at the end of this post between Juan and myself we have a variant of this working in v4 and v5.

[woodwoerk]

Thanks @GoldenChrysus, we kept playing around with this (and also tried your fork) and found a solution that worked for us. I'm not sure if it'll work for your use case, but I've outlined it here.

[GoldenChrysus]

Yep saw that, nice find @woodwoerk. It looks good but probably not a simple redirectProxyUrl for all providers. For example I also use Nodemailer which doesn't accept a URL override so I would need to override sendVerificationRequest as well (which I already do, but just as an example in the case that I didn't). So the workload may vary per provider. Also interesting that I guess you're forcing it to work by setting redirectProxyUrl on the provider in the first place (is host the multi-tenant host? Since it's not x-forwarded-for). Like I mentioned in my post, I have redirectProxyUrl set to my primary domain since an OAuth provider will only redirect to the registered callback URL and is often a space-limited, exhaustive list with no wildcards.

[woodwoerk]

That's right, our custom OAuth provider is quite flexible, we're forming an allowlist of redirect URLs based on the domains registered in our CMS. Our provider then throws an error if the passed redirectProxyUrl isn't found in the allowlist. So as you said, this approach probably won't work with the GitHub provider or others that limit the amount of redirect URLs. Yeah, host is indeed the multi-tenant host.

[pdparchitect]

You can use this ugly hack for v4 and maybe v5.

  const nextAuthHandler = NextAuth({
    ...
  })

...
...
...

  const hackedResponse = new Proxy(res, {
    get(target, prop) {
      if (prop === 'send') {
        return (body) => {
          debug(`* sending response`, { body })

          if (typeof body === 'string') {
            body = fixUrls(body)
          } else {
            body = JSON.parse(fixUrls(JSON.stringify(body)))
          }

          debug(`* fixed response`, { body })

          return res.send(body)
        }
      } else if (prop === 'json') {
        return (body) => {
          debug(`* sending json response`, { body })

          body = JSON.parse(fixUrls(JSON.stringify(body)))

          debug(`* fixed response`, { body })

          return res.json(body)
        }
      } else {
        return Reflect.get(target, prop)
      }
    },
  })

  return nextAuthHandler(req, hackedResponse)

The way it work is that we proxy the response object and correct the response urls using fixUrls function. I hope it helps!

[juan-altatech]

can't we add an baseUrl to NextAuthConfig that will supersede AUTH_URL or NEXTAUTH_URL here?

i.e. something like this:

export function reqWithEnvURL(req: NextRequest, config?: NextAuthConfig): NextRequest {
  const url = config?.baseUrl ?? process.env.AUTH_URL ?? process.env.NEXTAUTH_URL
  if (!url) return req
  const { origin: envOrigin } = new URL(url)
  const { href, origin } = req.nextUrl
  return new NextRequest(href.replace(origin, envOrigin), req)
}

Then we can set it within our NextAuth implementation:

export const { handlers, auth, signIn, signOut } = NextAuth((req?: NextRequest): NextAuthConfig => {
  const baseUrl = // set your baseUrl here depending on your req.
  return {
    baseUrl,
    ...
  }
}

looks like a 5 line PR, or so. Happy to contribute if this makes sense.

PS. for multitenancy or reverse proxied apps, what is currently in place is not enough. AUTH_TRUST_HOST only works for calls to auth, not for oauth provider redirects.

[GoldenChrysus]

This is the only concept that worked for me. The above code looks to be for v4, so my solution for v5 is a little different. I forked from the beta.20 tag (using master gave various errors in @auth/core) and added baseUrl?: (req: NextRequest) => string | undefined to the NextAuthConfig definition, and reqWithEnvURL is updated with const url = config?.baseUrl(req) ?? process.env.AUTH_URL ?? process.env.NEXTAUTH_URL. All reqWithEnvURL calls updated to add the config into the arguments.

Not sure if AUTH_TRUST_HOST=true is still needed (don't feel like testing) but I've left it as-is. NEXTAUTH_URL is not defined.

The other solutions get close but seem to not work behind a reverse proxy. e.g. AUTH_TRUST_HOST=true and following the preview deployment guide results in redirects to localhost:3000 for all auth types, including simple ones like Nodemailer (which the preview guide does not cover). Even though the various X-Forwarded* headers are properly set. I also lose the proper URL in the callback, so if I specify tenant.example.com/my/callback in the callback URL, it will be incorrectly set to example.com.

---

I've published this for my own usage, and I would suggest someone do the same on their own if we can't get a solution formally accepted, but my variant can be used like: "next-auth": "npm:next-auth-chrysus@^5.0.0-beta.23"

---

Depending on the OAuth provider, you may still need a proxy redirect like suggested in the preview deployment guide. For example, GitHub is quite strict in the redirect URLs allowed; you are afforded 10 with no wildcards and they must match exactly, so multi-tenant redirects seem to be out of the question here. Like the guide suggests, setting redirectProxyUrl on the provider with a non-multi-tenant URL worked fine. Other providers like Nodemailer or more lenient OAuth providers are able to redirect to the multi-tenant URL.

[juan-altatech]

nice! I ended up wrapping the GET and POST handlers in a custom function that does what I outlined above.

[woodwoerk]

We managed to get multi-tenant authentication working (version 5.0.0-beta.22) with an OIDC provider without forking the repo.

The missing piece seemed to be the redirect callback in the auth config. Credit to @juyrjola who discovered this by stepping through the code, it doesn't seem to be documented in the v5 docs yet. Here's what we do:

1. Use lazy Auth.js initialisation by passing a function to NextAuth which returns the configuration.
2. Get the protocol and host from next/headers for each request (which gives us the URL the user is signing in on).
3. Return the URL formed in step 2 in the redirect callback.
4. Set the redirectProxyUrl to the URL from step 2 followed by /api/auth. This ensures the redirect_uri of the authorisation request is correct.

I'd be interested to know if this works for others, here's a simplified version of our auth config:

import { headers } from 'next/headers';
import NextAuth from 'next-auth';
import type { OIDCConfig } from '@auth/core/providers';

export const {
  handlers: { GET, POST },
  auth,
} = NextAuth(() => {
  const headersList = headers();
  const protocol = headersList.get('x-forwarded-proto');
  const host = headersList.get('host');
  const url = protocol && host ? `${protocol}://${host}/api/auth` : null;

  if (!url) {
    console.error('Invalid request url');
    return { providers: [] };
  }

  return {
    callbacks: {
      jwt({ token, account, profile }) { ... },
      session({ session, ...params }) { ... },
      redirect() {
        return `${protocol}://${host}/`;
      },
    },
    providers: [
      {
        id: 'oidc-provider',
        name: 'Test OIDC Provider',
        type: 'oidc',
        issuer: process.env.AUTH_ISSUER,
        clientId: process.env.AUTH_CLIENT_ID,
        clientSecret: process.env.AUTH_CLIENT_SECRET,
        profile(profile) {
          return { name: profile.name };
        },
        wellKnown: `${process.env.AUTH_ISSUER}/.well-known/openid-configuration`,
      } satisfies OIDCConfig<Profile>,
    ],
    secret: process.env.AUTH_SECRET,
    redirectProxyUrl: url,
    trustHost: true,
  };
});

[Netyson]

I'm currently facing a similar challenge and appreciate your example.

I'm using Auth.js to manage authentication across multiple domains within the same codebase. Specifically, I'm successfully logging in at https://domain.com/login using a custom OIDC provider, and I can use the session data throughout the https://domain.com/* instance. However, I need the session to be accessible across multiple subdomains like dashboard.domain.com, pay.domain.com, and even across different domains like domain.net.

The domains are correctly redirected via middleware, and my session configuration is set as follows:

/auth.ts

session: {
  strategy: "database",
},

Here’s an example of the middleware setup:

export default auth((req) => {
    let hostname = req.headers.get("host");
    let pathname = req.nextUrl.pathname === "/" ? "" : req.nextUrl.pathname;

    switch (hostname) {
        case "domain.com":
            return NextResponse.next();
        case "domain.net":
            return NextResponse.rewrite(new URL(`/domain-net${pathname}`, req.url));
        case "dashboard.domain.net":
            return NextResponse.rewrite(new URL(`/dashboard-domain-comt${pathname}`, req.url));
        default:
            return NextResponse.next(); // Only accept requests from valid domains
    }
});

The application structure looks like this:

src
- app
  -- domain-com
  -- domain-net
  -- dashboard-domain-com
  -- ...

I’m encountering this error:

[auth][error] InvalidCheck: state value could not be parsed. Read more at https://errors.authjs.dev#invalidcheck

I suspect this issue arises because the cookies are only set for one domain, causing failures when accessing the session or attempting to log in from another domain.

Has anyone dealt with a similar issue or have suggestions on how to resolve this? Any tips would be greatly appreciated!

Thanks in advance!

[GoldenChrysus]

@Netyson If you want shared sessions across not only subdomain.domain.com but also domain.net then I think you have no choice but to create some central authority to issue tokens. You wouldn't actually share sessions: I'm pretty sure that's impossible as you can't have domain.net read a domain.com cookie. You would need requests to the authenticated portions of those domains to pass through your centralized service and then redirect back to the original domain, where they will now have a valid token and so a valid session.

It's not too different from a multi-tenant problem except I guess you want this to be totally seamless for your users. Meaning you don't want subdomain.domain.com, domain.net, etc. to each have to initiate their own authentication requests with third-party OAuth/OIDC/etc. providers like they would in a multi-tenant system.

Maybe you could get around that by setting up domain.com as its own OAuth provider? Users on domain.com would authenticate with, say, Google OAuth as normal. But users on subdomain.domain.com or domain.net would be limited to using domain.com OAuth, so they will be redirected to domain.com to login where they may or may not already have a session and domain.com will be responsible for negotiating that.

Really it sounds like you want to write your own SAML system where domain.com serves as the IdP for subdomain.domain.com and domain.net. Probably also an option. Maybe I'm overthinking it.

---

I should clarify that I think this the normal multi-tenant solutions won't work because the multi-tenant flow (using Google OAuth) is like:

1. domain.net initiates a Google OAuth login.
2. User authenticates with Google and is redirected back to domain.com.
3. domain.com forwards the user back to domain.net with a session.

This can be accomplished with the multi-tenant strategies discussed here.

But the slightly different flow I assume you want is:

1. User accesses domain.net.
2. To get a seamless login we must redirect the user somewhere where they already have a session, so we redirect them to domain.com and cross our fingers.
3. If the user isn't logged in then domain.com initiates the Google OAuth login.
4. User authenticates with Google and is redirected back to domain.com.
5. domain.net wasn't involved in this authentication exchange and still has no session. domain.com needs to communicate the authenticated state to domain.net, be it via SAML, OAuth, etc.

That said, a dubious way to get that to work is to have domain.com POST its JWT back to domain.net and domain.net will use that. Or more generally domain.com will make a JWT that domain.net can use. You would of course have to write something to prevent JWT forgery and since domain.com acts like an identity provider in this case it seems better to just properly implement it as an identity provider.

[Dragosp33]

We managed to get multi-tenant authentication working (version 5.0.0-beta.22) with an OIDC provider without forking the repo.

The missing piece seemed to be the redirect callback in the auth config. Credit to @juyrjola who discovered this by stepping through the code, it doesn't seem to be documented in the v5 docs yet. Here's what we do:

1. Use lazy Auth.js initialisation by passing a function to NextAuth which returns the configuration.
2. Get the protocol and host from next/headers for each request (which gives us the URL the user is signing in on).
3. Return the URL formed in step 2 in the redirect callback.
4. Set the redirectProxyUrl to the URL from step 2 followed by /api/auth. This ensures the redirect_uri of the authorisation request is correct.

I'd be interested to know if this works for others, here's a simplified version of our auth config:

import { headers } from 'next/headers';
import NextAuth from 'next-auth';
import type { OIDCConfig } from '@auth/core/providers';

export const {
  handlers: { GET, POST },
  auth,
} = NextAuth(() => {
  const headersList = headers();
  const protocol = headersList.get('x-forwarded-proto');
  const host = headersList.get('host');
  const url = protocol && host ? `${protocol}://${host}/api/auth` : null;

  if (!url) {
    console.error('Invalid request url');
    return { providers: [] };
  }

  return {
    callbacks: {
      jwt({ token, account, profile }) { ... },
      session({ session, ...params }) { ... },
      redirect() {
        return `${protocol}://${host}/`;
      },
    },
    providers: [
      {
        id: 'oidc-provider',
        name: 'Test OIDC Provider',
        type: 'oidc',
        issuer: process.env.AUTH_ISSUER,
        clientId: process.env.AUTH_CLIENT_ID,
        clientSecret: process.env.AUTH_CLIENT_SECRET,
        profile(profile) {
          return { name: profile.name };
        },
        wellKnown: `${process.env.AUTH_ISSUER}/.well-known/openid-configuration`,
      } satisfies OIDCConfig<Profile>,
    ],
    secret: process.env.AUTH_SECRET,
    redirectProxyUrl: url,
    trustHost: true,
  };
});

@woodwoerk How should Google login be handled via this? Google won't allow for a redirect if the url is not present in the google console of authorized redirects

[antosubash]

Here's how I solved the issue: I used NextAuth solely for OIDC (OpenID Connect) without leveraging any other features. If you're facing a similar problem, check out this blog post for more details: https://blog.antosubash.com/posts/openid-connect-with-nextjs.

[GoldenChrysus]

TL;DR: After committing a substantial amount of my own time to this package, including making my own fork to solve some problems as discussed above, realized that Vercel garbage is Vercel garbage; migrated to Lucia in under a day.

Edit: 3 days after trying out Lucia, I have now fully removed all Auth.js code and dependencies from my application, and multi-tenant cross-domain login is now working exactly as I had originally wanted it to with Auth.js. The only outstanding item is to implement either magic links or traditional user/pass, as I had not yet decided (even with Auth.js) which I want to use as my non-OAuth solution.

Original comment:

---

I thought I had this solved on my end but as I added more enterprise features and did more extensive testing, Auth.js totally fell apart. I'm now testing across several real domains/subdomains. There's something wrong with the way cookies are handled when using a proxy redirect such that the state cookie is cleared. You also can't use check: ['none'] in your OAuth provider because it forcibly adds 'state' to the array if using the proxy redirect. If you change the Auth.js code itself to ignore the state check anyway, login fails due to missing access_token and various other issues, even though you can see Auth.js making database calls to read/update accounts based on the provider_id, access_token, etc. that it received from the provider. Did extensive debugging of this in the NextAuth and Auth.js code yesterday, but ultimately decided an auth package that requires this much of my time to fix their own code is not worth it.

Following the preview deployment guide as written does not work -- and it also redirects to the wrong URL (hence why I had to make my own next-auth package to override this). But even a clean install to beta.25 without my package does not work at all.

I think that since this is a "preview deployment" guide, the expectation is that you're running (deploying) a fully isolated instance on the tenant, i.e. an on-prem deployment. This would work because then you could set NEXTAUTH_URL equal to the tenant. I believe what this actually means is that true multi-tenancy is not supported, i.e. a central service serving multiple tenants, so maybe I and others have misinterpreted the preview deployment guide to be a multi-tenancy guide. In my case, tenant domains are just proxied to the central service after TLS termination so there will never be isolated instances running.

At a broader level not related specifically to multi-tenancy but contributing to my distaste for this package, it's also problematic that the auth logic is totally separate from the application logic. Have to rely on hooking into callbacks and potentially implementing race conditions (specifically if using the event callbacks). Otherwise have to hijack the jwt and signIn callbacks to do provisioning logic which is not great.

---

Originally I had avoided solutions like Lucia because they would require me investing time into writing a bunch of auth logic. But I've now spent weeks on and off trying to resolve Auth.js problems. Although Lucia v3 will be deprecated next year, it's ultimately a pretty simple library, though that's also why it requires writing some of your own auth logic. Even so, I rewrote 80% of my auth logic in about 4-5 hours yesterday.

The proxy redirect was the first thing I implemented, making sure I could solve this huge Auth.js feature gap before doing anything else:

1. Create a signed JWT state with some info like the tenant redirect URL and write to cookie
2. Create an authorization URL to redirect to the OAuth provider that redirects back to the proxy domain
3. Receive OAuth response at the proxy domain callback handler
4. Verify state JWT signature and redirect the request (including OAuth search params) to the verify handler (whether that be intra-domain or at a tenant)
5. Verify state cookie and exchange the OAuth code
6. Do any business-level account provisioning and create the Lucia session

This was all very simple so I have no idea why it's nearly impossible in Auth.js. From what I've read of Auth.js' docs about the redirect proxy, the above is more or less what the Auth.js proxy redirect does anyway, so it's very strange to me that arguably the simplest part (writing the cookie at the tenant domain) is completely broken in Auth.js unless you set NEXTAUTH_URL.

With an additional hour, converted my API to read the Lucia session ID rather than the Auth.js JWT to get the authenticated user. This is a pretty smooth conversion thanks to Auth.js and Lucia sharing some tables (users and sessions) and only a few minor changes were required to the tables. You also get the benefit of using proper sessions instead of JWTs.

Also redid most of the front-end session state management. I already had my own contexts to guarantee a session (instead of always using Auth.js' useSession as it may be undefined) so I wrote my own useSession that provides the Lucia session from my existing contexts. This was about 30 minutes.

Now it's just a matter of rewriting my logic to switch between tenants for the current user, which was some gross code I had to stuff into the jwt callback to make API calls (verify the tenant change is allowed, etc.). Now it'll just be a normal handler that talks to my API.

---

Given that setting NEXTAUTH_URL equal to your tenant URL works with the proxy redirect, per the preview deployment limitations I mentioned above, some of the suggestions in this discussion to override process.env.NEXTAUTH_URL may work, but there are limitations:

• For starters, you're doing runtime changes to the env. I don't know if this is thread-safe. I don't feel like finding out in production.
• It won't work if you have a separate auth.ts and auth.config.ts as described in Edge Compatibility. This is because you don't have access to the request in auth.config.ts yet it is what will run in some of your middleware. This was my case because I use the Node Postgres adapter and the Nodemailer provider which needs the SMTP transport package. I could use the Neon HTTP Postgres adapter and move my mailing logic to the API, but that would all be in an effort to...be able to override the environment at runtime. So a gross fix to enable a different gross fix.

[MrVibe]

This is highly useful comment ! Thanks for guidance.