Supabase auth for same session on multiple sub domains

[loekj]

Hi,
Is it possible to have a session created on app.mydomain.com be valid on *.mydomain.com?
I am hosting a simple landing page on Vercel and it will need to have a logged-in section as well; accessing the user's date to alter the landing page.
On app.mydomain.com will be a separate React app.

I'm considering using Supertokens.io because they are more flexible than Auth0 and it should be possible there. Even better I'd stick with Supabase if this is possible. Anyone here has any idea? :)

[romshiri]

Did you find any solution to this? facing the same issue..

[gitmolejon]

Same here 👀

[jtiulentino]

me too...

[jtiulentino]

According to this issue, it should be possible... but I followed the instructions in there to add wildcard subdomains, and I still get a null User object in the subdomains.
Supabase auth currently does not allow a single login session across subdomains: #473

[AlbertIsernAlvarez]

Sameeeee, but I thought about making a gateway using rest API only for the user, I hope it works.

[hf]

Hey everyone, I'm on the Auth team.

If I understand correctly, your question is about whether two different apps, that exist both on a.example.com and b.example.com can share the same login session?

This is definitely doable, but it's not well documented.

When using Auth Helpers

You can pass a domain option when calling createBrowserSupabaseClient which will follow the semantics of the Domain cookie attribute.

When using the JS library on your own

You can do this by using a hand-crafted cookie using the Domain cookie attribute to share existing access and refresh tokens with the other site.

In both of your applications, you need to add code similar to this:

supabase.auth.onAuthStateChange((event, session) => {
  if (event === 'SIGNED_OUT' || event === 'USER_DELETED') {
    // delete cookies on sign out
    const expires = new Date(0).toUTCString()
    document.cookie = `my-access-token=; Domain=example.com; path=/; expires=${expires}; SameSite=Lax; secure`
    document.cookie = `my-refresh-token=; Domain=example.com; path=/; expires=${expires}; SameSite=Lax; secure`
  } else if (event === 'SIGNED_IN' || event === 'TOKEN_REFRESHED') {
    const maxAge = 100 * 365 * 24 * 60 * 60 // 100 years, never expires
    document.cookie = `my-access-token=${session.access_token}; Domain=example.com; path=/; max-age=${maxAge}; SameSite=Lax; secure`
    document.cookie = `my-refresh-token=${session.refresh_token}; Domain=example.com; path=/; max-age=${maxAge}; SameSite=Lax; secure`
  }
})

Each time a new access and refresh tokens are issued on any site these cookies will get updated. Then you should also add this code next to the above callback:

const cookies = document.cookie.split(/\s*;\s*/).map(cookie => cookie.split('='));
const accessTokenCookie = cookies.find(x => x[0] == 'my-access-token');
const refreshTokenCookie = cookies.find(x => x[0] == 'my-refresh-token');

if (accessTokenCookie && refreshTokenCookie) {
  await supabase.auth.setSession({
    access_token: accessTokenCookie[1],
    refresh_token: refreshTokenCookie[1],
  })
}

This snippet extracts the cookies (that either of the sites set) and forces the client library to use those.

Notice the addition of Domain=example.com. Per the MDN documentation:

The Domain attribute specifies which hosts can receive a cookie. If unspecified, the attribute defaults to the same host that set the cookie, excluding subdomains. If Domain is specified, then subdomains are always included. Therefore, specifying Domain is less restrictive than omitting it. However, it can be helpful when subdomains need to share information about a user.

For example, if you set Domain=mozilla.org, cookies are available on subdomains like developer.mozilla.org.

If you need multiple domains, you would need to set cookies multiple times with the different top-level domain.

Note that this cookie approach does not signal to tabs currently opened on the other site. This is very difficult to do right, but you can improve the user experience by checking for the cookies (as shown in the snippet above) just before you call a signIn function.

[AlbertIsernAlvarez]

What about using different domains? But with a central domain for authentication (auth.domain.com)

[kernelguardian]

createBrowserSupabaseClient seems to be depreciated. https://supabase.com/docs/guides/auth/auth-helpers/nextjs#migrating-to-v07x

[WJimmyCook]

It seems that calling setSession() triggers a SIGNED_IN event, so if you call setSession every time a SIGNED_IN event is triggered in onAuthStateChange then it results in an infinite loop and every loop makes a request the /user endpoint in supabase. Am I doing something wrong?

[bubbleheadinc]

@WJimmyCook Same issue. Ever find a solution?

[WJimmyCook]

@bubbleheadinc nope, unfortunately never figured it out. Just ended up not implementing it. Had to move on to higher priority stuff.

[berik]

Example of using Auth helper in Next.js using TS

export default function App({
  Component,
  pageProps,
}: AppProps<{ initialSession: Session }>) {
  // Create a new supabase browser client on every first render.
  const [supabaseClient] = useState(() =>
    createBrowserSupabaseClient<Database>({
      cookieOptions: {
        domain: "example.com",
        maxAge: "100000000",
        path: "/",
        sameSite: "Lax",
        secure: "secure",
      },
    })
  );

  return (
    <SessionContextProvider
      supabaseClient={supabaseClient}
      initialSession={pageProps.initialSession}
    >
      <Component {...pageProps} />
    </SessionContextProvider>
  );
}

if authenticate on main page, then the cookie will be available on a.example.com and b.example.com

[chhuang]

I tried on with .vercel.app and vercel.app but it didn't work, it doesn't even let me log in (I'm logging in with Google).

Do you guys know why?

[berik]

Hey @chhuang ,I had some issues with .vercel.app too so I've bought the custom domain and worked correctly.
This thread helped to fix multitenant issue: vercel/platforms#69

Hope it helps

[tomekit]

Using this approach I've got duplicate cookies, one on: .example.com (new) and 2nd one on the subdomain.example.com (original).
The issue is that I can't logout user, as only: .example.com cookie is being removed, where as: subdomain.example.com persists, so next time when user visits page they're authorized.

Also described here:
https://github.com/orgs/supabase/discussions/3198#discussioncomment-5748383

[lucasishuman]

I am following the technique described above in my Next.js project - I have one 'auth' subdomain that is responsible for handling sign in + setting top-level domain cookies and sign out by deleting them. Then there are several other subdomains that all require a user to be signed in.

I also noticed that the subdomains still automatically set cookies on the subdomain even though I was specifying the session to use manually.

My workaround for this is to manually strip out the auth token cookie on all my subdomains in my Next.js middleware responses (I was already ready using middleware to make sure users are signed in for all of my subdomains except the one responsible for 'auth'), like...

export async function middleware(req: NextRequest) {
  // We need to create a response and hand it to the supabase client to be able to modify the response headers.
  const res = NextResponse.next();

  // Create authenticated Supabase Client.
  const supabaseClient = createMiddlewareSupabaseClient({ req, res });

  // Check if we have a session
  const {
    data: { session },
  } = await supabaseClient.auth.getSession();

  // Check auth condition
  if (session?.user) {
    // Authentication successful, forward request to protected route.
    // NOTE: deleting this subdomain-specific cookie is necessary so make the top-level cookies work
    res.cookies.delete('supabase-auth-token'); // <-- THIS IS THE IMPORTANT BIT
    return res;
  }

  const signInUrl = '[my sign in url]';
  return NextResponse.redirect(signInUrl);
}

I wish this wasn't necessary and maybe there's a better way to do it... 🤷🏼‍♂️

Hopefully Supabase can implement a better way to handle auth + users + sessions across subdomains in the future 🤞🏻

[JorensM]

When I try this and inspect my request in devtools, I don't see the appropriate headers being attached to the request, nor the cookie.

[Necmttn]

A small bug fix for nextjs app dir users;
supabase/auth-helpers#604
which enables to use subdomain auth

[kevin-eberhardt]

Is this solution also available for supabase/ssr, since auth-helpers is supposed to be replaced by it?

[thedevdavid]

Is there anything about how this works with supabase/ssr?

[uncvrd]

I'm just getting my feet wet with Supabase Auth but I found out you can set a .yourdomain.com cookie doing the following:

import { createBrowserClient } from "@supabase/ssr"

const supabase = createBrowserClient<Database>(env.NEXT_PUBLIC_SUPABASE_PROJECT_URL, env.NEXT_PUBLIC_SUPABASE_ANON_KEY, {
        cookies: {},
        cookieOptions: {
            domain: `yourdomain.com`,
        },
})

Typescript will give you a fuss unless you add that cookies object for some reason but this works so far...

Maybe someone else can add anything else that may be needed?

[Jaaneek]

Any updates on this?

[scrabase]

Any simple way to do this with nextjs 14?

[GabrielFabian]

Has anyone been able to redirect their users from their main domain (example.com) to their sub-domain (app.example.com) where app.example.com is a completely different project within vercel while remaining authenticated? I'm handling auth via middleware the way the docs suggest .

Predictably, since the project that hosts app.exaple.com is on a different server, I can't pass the sessions around as I'd like.

[GabrielFabian]

I was able to figure this out, here's what I did.

• server action handles form submit on project w/ apex domain
• set sb-auth cookie
• ensure cookie options object is configured correctly

export const signInWithPassword = async (formData: FormData) => {
	const email = formData.get("email") as string;
	const password = formData.get("password") as string;
	const supabase = createClient();

	const { data, error } = await supabase.auth.signInWithPassword({
		email,
		password,
	});

	if (error) {
		return redirect("/auth/signin?auth=failed");
	}

	if (process.env.NODE_ENV === "production") {
		cookies().set("sb-auth", JSON.stringify(data.session), { // cookie options
			httpOnly: true,
			secure: process.env.NODE_ENV === "production",
			sameSite: "lax",
			path: "/",
			domain: ".example.com",
			expires: new Date(data.session?.expires_at?.toString() || 0),
		});
		return redirect("https://app.example.com/admin");
	}

	return redirect("/admin"); // on localhost, don't worry about cookies
};

• in subdomain project middleware, detect cookie assigned from apex domain
• set session w/ cookie value

//middleware.ts
if (request.cookies.get("sb-auth")) {
		const session: Session = JSON.parse(request.cookies.get("sb-auth")!.value!);
		const response = await supabase.auth.setSession(session);
}

Gotcha: assure that on log out, you're removing sb-auth cookie and whatever auth cookies supabase sets.

[Rhys97W]

Anyone found a solution to this? I am trying to replicate the Vercel Platforms Starter Kit but cannot get cross-domain auth working with Supabase at all

[ramezj]

Any updates on this?

[hsab]

If anyone else is running into this I recommend having a look at #27283 (comment)