DEV Community: cio fea

How do I make NextAuth work with multiple domains?

cio fea — Thu, 15 Oct 2026 10:41:19 +0000

I’m building loginos, a sign-in service for products that run on more than one domain. This question comes up a lot, so here is the full answer: the general approach first, then how loginos handles it.

Short answer: Leave AUTH_URL and NEXTAUTH_URL unset and turn on trustHost, so Auth.js builds its URLs from the host of each request instead of one fixed domain. Each domain then keeps its own session cookie, and your identity provider must accept the Auth.js callback URL on every domain. With loginos, someone signed in on one domain comes back on the others without a form.

You run one Next.js app on several domains, like app.example.com, example.net and domains your customers connect. NextAuth.js, now called Auth.js, signs people in on one of them and misbehaves on the rest: it sends them back to the wrong host, or stops with an UntrustedHost error. One deployment can serve every domain. Auth.js has to build its URLs from each request, each domain keeps its own session, and your identity provider has to accept a callback on every domain.

How does Auth.js decide which URL to use?

Auth.js needs your app’s own address to build the sign-in redirect, the redirect_uri it sends to the provider, and the page people land on afterwards. Auth.js v5, which you install as next-auth@beta, finds that address in one of three ways:

Your setup	Address Auth.js uses	Works on many domains?
`AUTH_URL` or `NEXTAUTH_URL` is set	That URL, for every request	No: every callback goes to one domain
Neither is set, and the host is trusted	The host of each request, from `X-Forwarded-Host` or `Host`	Yes
Neither is set, the host isn’t trusted, in production	None: Auth.js stops with `UntrustedHost`	No

AUTH_URL, and its older name NEXTAUTH_URL, pin everything to one domain: next-auth rewrites the origin of each incoming request to that URL. A sign-in that starts on example.net then tries to come back to app.example.com. For several domains, remove both variables from every environment.

The host counts as trusted when you set trustHost: true in your config or AUTH_TRUST_HOST=true in the environment. Auth.js also trusts it by itself on Vercel and Cloudflare Pages, and whenever NODE_ENV isn’t production. That last rule is why a multi-domain setup can work on your laptop and fail after you deploy.

Trusting the host is safe when your hosting platform or reverse proxy sets these headers itself, instead of passing on whatever a client sends. The Auth.js deployment guide covers the setting. Your provider’s callback allow list is a second check, because a forged host only produces a callback URL that the provider refuses.

On a self-hosted server, fix the route handler URL

Server actions and auth() read the host from the headers, but the Auth.js route handlers use the request’s URL. A self-hosted Next.js server started with next start reports that URL as an internal address, like http://localhost:3000, whatever domain the visitor used. The callback then sends the wrong redirect_uri with the code, and the exchange fails. Rebuild the URL from the forwarded host before Auth.js sees it:

import { NextRequest } from "next/server"
import { handlers } from "@/auth"

// Give Auth.js the URL the visitor used, not the server's internal address.
const onPublicHost = (handler: (req: NextRequest) => Promise<Response>) => (req: NextRequest) => {
  const host = req.headers.get("x-forwarded-host") ?? req.headers.get("host")
  const proto = req.headers.get("x-forwarded-proto") ?? "https"
  const { pathname, search } = req.nextUrl
  return handler(new NextRequest(new URL(pathname + search, `${proto}://${host}`), req))
}

export const GET = onPublicHost(handlers.GET)
export const POST = onPublicHost(handlers.POST)

Where the URL is already right, the wrapper changes nothing. On Vercel, for example, X-Forwarded-Host is the same as the Host the visitor used.

Why does each domain get its own session?

Auth.js keeps the session in a cookie named authjs.session-token, or __Secure-authjs.session-token on HTTPS. Auth.js sets that cookie without a Domain attribute, so the browser sends it back only to the exact host that set it. A session on app.example.com is invisible to example.net, because browsers never send one domain’s cookies to another.

So “NextAuth on multiple domains” means that each domain signs the person in on its own. The default redirect callback also only allows redirects to the origin of the current request, so someone who starts on example.net ends on example.net.

What makes this painless is the identity provider’s own session. When the second domain sends someone to the provider, the provider recognizes them and sends them straight back with a code, without a form. The answer on sharing a login session across domains walks through that flow.

Which callback URLs must the provider accept?

Auth.js sends the provider redirect_uri=https://<current host>/api/auth/callback/<provider id>. For a provider with the id loginos, that is https://example.net/api/auth/callback/loginos on example.net. The provider must accept that exact URL on every domain, or it refuses the sign-in.

You have three ways to get there:

List every callback URL in the provider’s settings. That’s fine for two or three domains, and a chore once customers bring their own.
Use the Auth.js redirect proxy. With AUTH_REDIRECT_PROXY_URL, one stable deployment receives every callback and forwards it to the URL that started the sign-in. Auth.js built it for preview deployments and calls it an option for advanced cases. Every deployment must share the same AUTH_SECRET.
Use a provider built for many domains, with an API for adding them and wildcards for subdomains. Wildcards have their own rules: see wildcard redirect URIs.

How loginos does it

loginos is a hosted OpenID Connect provider for one product on many domains. A platform has no limit on domains, and they all share one user pool, so you never maintain a list of callback URLs by hand.

Create a platform in the developer console, with a name and your first domain. Copy the app secret: it is shown once.
In the console, set the platform’s callback path to /api/auth/callback/loginos. The path is the same on every domain, and loginos only redirects to https://<one of your domains><callback path>.
Add your other domains in the console, from your server, as a verified wildcard like *.example.com, or as automatic domains that your server confirms the first time they’re used.
Add loginos to Auth.js as an OpenID Connect provider, and copy roles and permissions from the ID token into the session:

import NextAuth, { type DefaultSession } from "next-auth"

declare module "next-auth" {
  interface Session {
    user: { roles: string[]; permissions: string[] } & DefaultSession["user"]
  }
}

export const { handlers, auth, signIn, signOut } = NextAuth({
  trustHost: true, // use each request's host; don't set AUTH_URL
  providers: [
    {
      id: "loginos", // callback: /api/auth/callback/loginos
      name: "loginos",
      type: "oidc",
      issuer: "https://loginos.io",
      clientId: process.env.LOGINOS_APP_KEY,
      clientSecret: process.env.LOGINOS_APP_SECRET,
      checks: ["pkce", "state"],
    },
  ],
  callbacks: {
    jwt({ token, account, profile }) {
      // Only at sign-in: profile holds the claims of the loginos ID token.
      if (account && profile) {
        token.sub = account.providerAccountId // the loginos sub, the same on every domain
        token.roles = profile.roles
        token.permissions = profile.permissions
      }
      return token
    },
    session({ session, token }) {
      session.user.id = token.sub as string
      session.user.roles = token.roles as string[]
      session.user.permissions = token.permissions as string[]
      return session
    },
  },
})

Auth.js reads the endpoints from https://loginos.io/.well-known/openid-configuration, sends PKCE and state, and checks the ID token. The jwt callback copies the loginos sub on purpose: without a database adapter, Auth.js gives every sign-in a new random user id. Key your own records on session.user.id, never on the email address, because loginos doesn’t verify email addresses yet. Tokens carry the roles someone had when they signed in, and roles and permissions shows how to read the current ones.

What happens on the second domain

Someone who signed in on app.example.com opens example.net for the first time. Auth.js on example.net has no session cookie for them yet.

They click your sign-in button, which calls signIn("loginos") in a server action.
Auth.js redirects to loginos with redirect_uri=https://example.net/api/auth/callback/loginos.
loginos finds its own session and sees that the person already uses your platform, so it sends them straight back with a code. There is no form.
Auth.js exchanges the code on your server and sets the session cookie for example.net.

Tip: To check without ever showing a page, pass prompt: "none" as the third argument: signIn("loginos", { redirectTo: "/" }, { prompt: "none" }). Someone who isn’t signed in to loginos comes back with error=login_required, which Auth.js turns into ?error=OAuthCallbackError on your sign-in page.

Auth.js is optional. The quickstart has a Next.js version with two plain route handlers, one that redirects and one callback, on the default callback path. On a self-hosted server, build their callback URL from the forwarded host as well. Plain handlers also leave room for loginos features that need your own requests, like account linking.

Frequently asked questions

Do I need a separate deployment for each domain?

No. One Next.js deployment can answer on every domain you point at it. Remove AUTH_URL and NEXTAUTH_URL, trust the host, and make sure the route handlers see the public URL. Then add each domain to your hosting and to your identity provider.

Can NextAuth share one session between example.com and example.net?

No. Auth.js stores the session in a cookie for the host that set it, and browsers never send one domain’s cookies to another. Each domain gets its own session. A central identity provider turns the second sign-in into a quick redirect instead of a form.

Is trustHost: true safe in production?

Yes, if your hosting platform or reverse proxy sets the Host and X-Forwarded-Host headers itself, instead of passing on what the client sent. Your provider’s callback allow list is a second check: a forged host only produces a callback URL that the provider refuses.

Does this work with NextAuth v4?

Yes. next-auth@latest still installs v4. Leave NEXTAUTH_URL unset and set AUTH_TRUST_HOST=true, and v4 builds its origin from X-Forwarded-Host or Host on every request. The callback path is the same, but v4 writes a custom OpenID Connect provider as type: "oauth" with a wellKnown discovery URL and idToken: true.

Is NextAuth still maintained?

Yes, with a narrower focus. Since September 2025 the Better Auth team maintains Auth.js. Its announcement says existing users can keep using it and will get security patches, and it recommends Better Auth for new projects. Version 5 still ships under the beta tag on npm: 5.0.0-beta.32 came out in July 2026.

Try loginos

loginos is an OpenID Connect provider that gives every domain of your product one shared sign-in:

Any number of domains, one user pool. Add them in the console or from your server, cover subdomains with a verified wildcard, or let your server approve new ones as people sign in.
Passkeys built in. Face ID, fingerprints and security keys, with passwords as a fallback, and no WebAuthn code in your app.
Roles and permissions in every token, the same on every domain.
Keep the users you have. People link their existing account once, and every token carries your own user id.
“Continue as” on your own page in Chrome and Edge, with a small loginos window everywhere else.
Standard OpenID Connect, so Auth.js, Passport or any OIDC library works. There are no paid plans today, and you can start without a card.

Create a platform in a few minutes, follow the quickstart, or read more answers like this one. This answer is kept up to date at loginos.io/answers.

Can I use wildcard redirect URIs with OAuth?

cio fea — Thu, 15 Oct 2026 10:41:03 +0000

Short answer: Usually not, and you shouldn’t rely on them. RFC 9700, the OAuth 2.0 Security Best Current Practice, requires authorization servers to match redirect URIs exactly, because loose patterns have let attackers steal authorization codes. Google rejects wildcards, while Auth0 and Okta allow narrow ones with warnings. Register exact URIs through an API instead, or use a provider that verifies wildcard ownership or asks your server.

You run many subdomains, or your customers bring their own domains, and registering a callback URL for each one by hand doesn’t scale. A pattern like https://*.example.com/callback looks like the obvious fix. The OAuth specs say no: a redirect URI should match a registered value exactly, character for character. Some providers still accept wildcards, with restrictions and warnings, and there are safer ways to get the same result.

What do the OAuth specs say about wildcard redirect URIs?

A redirect URI is the address where the authorization server sends the browser back after sign-in, with an authorization code. The code is what your app trades for tokens, so the redirect URI decides who gets it.

RFC 6749, the OAuth 2.0 framework from 2012, asked servers to require the complete redirect URI, but allowed registering only part of it when that wasn’t possible.
RFC 9700, the OAuth 2.0 Security Best Current Practice published in January 2025, updates RFC 6749 and closes that gap. Section 2.1 says authorization servers “MUST utilize exact string matching” when they compare redirect URIs. The only exception is the port of localhost redirect URIs in native apps.
OpenID Connect Core 1.0 requires the redirect_uri to exactly match a pre-registered value, compared as plain strings.
OAuth 2.1, still an Internet-Draft in October 2026, requires exact matching as well.

Exact means exact: same scheme, host, port, path and query. https://app.example.com/callback and https://app.example.com/callback/ are two different URIs.

Why are wildcard redirect URIs dangerous?

Your client ID is public, so anyone can build an authorization request for your app with a redirect URI of their choice. The server’s matching is the only thing that decides where the code goes. RFC 9700 describes three ways patterns fail:

Matching bugs. RFC 9700’s example registers https://*.somesite.example/*. A naive server reads * as “any characters” and accepts https://attacker.example/.somesite.example, a different domain entirely.
Subdomain takeover. Even correct matching trusts every subdomain. Subdomain takeover is when an attacker gains control of one of your subdomains, typically through a stale CNAME record that still points at a cloud service you stopped using. Once they claim that service, the wildcard hands them your users’ codes.
Open redirects. An open redirect is a URL on your site that forwards the browser to any address given in a parameter. A broad pattern can match such a URL, which then carries the sign-in response off your site. RFC 9700 forbids clients from exposing open redirectors.

What leaks is an authorization code, or a token in older flows that return one directly. A code alone isn’t enough for a confidential client, since the exchange needs your client secret. But an attacker can try to inject the stolen code into your own callback. PKCE (Proof Key for Code Exchange), which binds each code to a secret held by whoever started the sign-in, blocks that. Exact matching plus PKCE is the baseline.

Which providers allow wildcard redirect URIs?

Rules differ, and they change, so check your provider’s current docs. As of October 2026:

Provider	Wildcards in redirect URIs	Limits and warnings
Google	No	Redirect URIs can’t contain `*`, and `redirect_uri` must exactly match an authorized URI.
Microsoft Entra ID	Only for apps that sign in work or school accounts alone, added in the manifest editor	Not for apps that also sign in personal Microsoft accounts. Microsoft says to avoid them.
Auth0	One `*` in the subdomain furthest from the root	Matches one level only. Auth0 says not to use them in production and suggests `{organization_name}` placeholders.
Okta	One `*` in the lowest-level subdomain, once turned on per app	HTTPS only, not in paths or logout URIs. Okta calls wildcard subdomains an insecure practice.
Keycloak	At the end of a URL pattern, like `https://app.example.com/*`	A lone `*` allows any URL; the docs say not to use it in production.
GitHub OAuth apps	Optional wildcard matching per callback URL	Any subdomain or subdirectory of the callback URL matches. GitHub warns that attackers can then receive codes.

On GitHub, an OAuth app that had a single callback URL before August 3, 2026 has wildcard matching turned on for it, and GitHub recommends turning it off if you don’t need it.

What can you do instead of a wildcard?

Four approaches give you many domains without a loose pattern.

Verify the parent domain first

A wildcard is safer when the provider accepts it only after you prove control of the parent domain, usually with a DNS TXT record, and never lets it cover the parent domain itself. That rules out typos and patterns over domains you don’t control. The subdomains are still only as safe as your DNS, so remove records for services you no longer use.

Register exact URIs through an API

Auth0, Microsoft Entra ID and Amazon Cognito, among others, let your server change a client’s redirect URIs through a management API. Call it when a domain goes live and again when it goes away. Watch the caps. Auth0 allows 100 callback URLs per application and Amazon Cognito 100 per app client. Microsoft Entra ID allows 256 redirect URIs per app, or 100 if the app also signs in personal Microsoft accounts. How to add a redirect URI automatically has the code.

One fixed callback that redirects onward

Register a single callback, like https://login.example.com/callback, and carry a reference to the return address in state. After the code exchange, the callback sends the person on to the right domain. Microsoft documents this pattern as its alternative to wildcards. It has two catches:

The onward redirect is an open redirect unless you check the target against your own list. Keep the target itself out of state; Microsoft suggests a key that points to data you stored.
The session starts on the login domain. Subdomains can share a cookie set for the parent domain, but a customer’s own domain can’t, so it needs a one-time hand-off token: a small identity provider you now maintain. Authentication on customers’ custom domains compares the two designs.

Let your server confirm new domains

In this approach, the provider asks your server about each new domain the first time a sign-in comes from it, and your server answers from its own records. Nothing is trusted because of how a name looks.

RFC 9126, the spec for pushed authorization requests (PAR), has a related idea. When a client sends its request to the server first, with authentication, the server may accept a redirect URI that was never registered. That is optional, so check whether your provider does it.

How loginos does it

In loginos, the callback path is the same on every domain, so you register domains, not URLs. loginos only sends people back to https://<one of your domains><callback path>, exactly, with no query string. Three things cover many domains:

A verified wildcard. *.example.com covers every subdomain of example.com at any depth, but never example.com itself. You prove ownership once with a TXT record, and until loginos finds it, the wildcard matches nothing.
Exact hosts from your server. POST /api/v1/domains takes up to 1,000 hosts at once and is safe to repeat, and DELETE /api/v1/domains/{host} removes one. A platform has no limit on domains.
Automatic domains. loginos asks your server about an unknown host the first time someone signs in there, and adds it only if your server says yes. See automatic domains.

The record that proves you own example.com:

Type   TXT
Name   _loginos.example.com
Value  loginos-verify=<the value the console or the API gives you>

Add the wildcard in the console’s Domains tab or from your server, then check the record:

curl -X POST https://loginos.io/api/v1/domains \
  -u "$LOGINOS_APP_KEY:$LOGINOS_APP_SECRET" \
  -H "content-type: application/json" \
  -d '{"host": "*.example.com"}'   # the answer includes the TXT record

curl -X POST "https://loginos.io/api/v1/domains/*.example.com/verify" \
  -u "$LOGINOS_APP_KEY:$LOGINOS_APP_SECRET"

Pushed requests get no shortcut: loginos applies the same domain check to /oauth/par as to the redirect flow. A wildcard can’t cover your customers’ own domains, so register those by name or confirm them with automatic domains. Domains has the details.

Frequently asked questions

Does RFC 6749 allow wildcard redirect URIs?

RFC 6749 left room for them. It asked servers to require the complete redirect URI. As a fallback, it allowed registering only part of it, such as everything except the query string, and some servers went further and accepted patterns. RFC 9700 updates RFC 6749 and requires exact string matching, so a server that follows current best practice doesn’t accept wildcards.

Can I vary the path or query string of a redirect URI?

Not with exact matching. Put per-request data in state, which the server returns untouched, or keep it in your session and put only a random key in state. RFC 6749 already suggested state for this.

Do I need wildcards for localhost?

No. For native apps that listen on a loopback address, RFC 9700 makes servers accept any port, so the app can pick a free one. For web development, register your local address exactly, like http://localhost:3001/callback, next to your production URIs.

Is a wildcard safe if I own every subdomain?

Safer, not safe. Every subdomain becomes a valid place to receive codes, including forgotten ones with stale DNS records and any subdomain where customers or users can publish their own pages. If you use one, audit your DNS records and remove the ones you no longer need.

Can PAR replace redirect URI registration?

Sometimes. RFC 9126 lets a server accept unregistered redirect URIs from clients that push their requests with authentication, but servers don’t have to. loginos doesn’t: a pushed request must use one of your domains like any other.

Try loginos

loginos is an OpenID Connect provider that gives every domain of your product one shared sign-in:

Any number of domains, one user pool. Add them in the console or from your server, cover subdomains with a verified wildcard, or let your server approve new ones as people sign in.
Passkeys built in. Face ID, fingerprints and security keys, with passwords as a fallback, and no WebAuthn code in your app.
Roles and permissions in every token, the same on every domain.
Keep the users you have. People link their existing account once, and every token carries your own user id.
“Continue as” on your own page in Chrome and Edge, with a small loginos window everywhere else.
Standard OpenID Connect, so Auth.js, Passport or any OIDC library works. There are no paid plans today, and you can start without a card.

Create a platform in a few minutes, follow the quickstart, or read more answers like this one. This answer is kept up to date at loginos.io/answers.

How do I share a login session across multiple domains?

cio fea — Thu, 15 Oct 2026 10:40:47 +0000

Short answer: You can’t share a session cookie between two different domains, because browsers only send a cookie to the domain that set it. Instead, each domain keeps its own session and gets it from one central login, an OpenID Connect provider. Someone who is already signed in there is sent straight back with a one-time code, without seeing a form.

You run more than one site, like app.example.com, example.net and shop.example.org, and you want someone who signs in on one of them to be signed in on the others. The obvious idea is to share the session cookie. That works for subdomains, but not for different domains, and no setting changes that. What you share instead is the sign-in: every domain asks the same place who the person is.

Why can’t two domains share a session cookie?

A cookie belongs to the site that set it. When example.com sets session=abc, the browser sends that cookie back to example.com and, if the cookie has Domain=example.com, to its subdomains. It never sends it to example.net. This rule is what stops any website from reading your bank’s session cookie, so browsers will not relax it.

Third-party cookies used to offer a workaround: an example.net page could load something from example.com and get that domain’s cookies with it. Safari and Firefox block third-party cookies by default, and storage inside iframes is now partitioned by the top-level site. Tricks built on hidden iframes or postMessage between your domains break for many of your users, often without an error.

What are your options?

There are three ways to sign someone in on more than one site. Which one fits depends on whether your sites share a parent domain.

Approach	Works across different domains?	What you build
One cookie for the parent domain	No, only for subdomains like `app.example.com` and `shop.example.com`	Nothing extra: set `Domain=example.com` on the session cookie
A central login (identity provider)	Yes, any number of domains	A redirect route and a callback route on each site
Hand a token from one site to the other	Yes, but you secure it yourself	One-time tokens, expiry, replay protection, redirect checks

One parent-domain cookie is the simplest when it fits. Everything under example.com can read a cookie set with Domain=example.com. It stops at the edge of that domain.

Handing tokens across means site A creates a short-lived token and redirects to site B with it in the URL, and site B trades it for a session. It works, but you end up writing a small identity provider: tokens that work once, expire fast, are bound to the target site, and never land in logs. Most teams who start here move to a real provider by the third domain.

A central login is the standard answer, and it is what “single sign-on” means on the web. One service, the identity provider, keeps its own session on its own domain. Every one of your sites sends people there to sign in and gets them back with a one-time code.

How a central login shares the sign-in

The protocol most providers speak is OpenID Connect (OIDC), a layer on top of OAuth 2.0 that tells your app who signed in. Here is what happens when someone who signed in on app.example.com opens example.net for the first time:

example.net has no session for them, so it redirects the browser to the provider, with its own address as the return address.
The provider sees its own session cookie, set when they signed in on app.example.com. It doesn’t show a form.
The provider sends the browser straight back to example.net with a code that works once.
The server of example.net exchanges the code for the person’s identity, then sets its own session cookie.

The person sees a short redirect and is signed in. Each domain still has its own session, and nothing crosses between domains except the browser itself, carrying a one-time code. That is why this works without third-party cookies.

Tip: To check for a sign-in without ever showing a page, add prompt=none to the redirect. The provider answers at once: with a code if the person is signed in, or with error=login_required if not.

What to watch out for

Check the return address. The provider must only send codes to addresses you registered. A provider that accepts any return address hands sign-in codes to whoever asks.
Exchange codes on your server. The code is worth nothing without your app’s secret, so the exchange belongs on the server, not in the browser.
Use state and PKCE. state ties the callback to the browser that started the sign-in, and PKCE stops a stolen code from being used.
Sign-out is per domain. Signing out of one site clears that site’s session. To end the central session too, send the browser to the provider’s logout address.
Don’t merge accounts by email unless the provider has verified the address. Use a stable user id (sub in OpenID Connect).

How loginos does it

loginos is an OpenID Connect provider built for exactly this: one product on many domains. You create a platform, add your domains (as many as you have), and they all share one pool of people. Someone who creates an account on one domain is already a member on the others.

On each domain you add two routes: one that redirects to loginos, and a callback that exchanges the code. The callback path is the same on every domain, /api/auth/login/single/callback by default, and loginos only sends people back to https://<one of your domains><callback path>.

const LOGINOS = "https://loginos.io";

// The callback, on every one of your domains.
app.get("/api/auth/login/single/callback", async (req, res) => {
  const [state, verifier] = (req.cookies.lo_flow ?? "").split(".");
  if (!state || req.query.state !== state) return res.status(400).send("Sign-in expired, try again.");

  const r = await fetch(`${LOGINOS}/oauth/token`, {
    method: "POST",
    body: new URLSearchParams({
      grant_type: "authorization_code",
      code: String(req.query.code ?? ""),
      redirect_uri: `https://${req.get("host")}/api/auth/login/single/callback`,
      code_verifier: verifier,
      client_id: process.env.LOGINOS_APP_KEY,
      client_secret: process.env.LOGINOS_APP_SECRET,
    }),
  });
  if (!r.ok) return res.status(401).send("Sign-in failed.");
  const { user } = await r.json(); // sub, preferred_username, roles, permissions…
  req.session.user = user; // this domain's own session
  res.redirect("/");
});

The quickstart has the redirect route and complete versions for Next.js, Express and PHP. A few things come with it:

No form on the second domain. Someone signed in to loginos who has used your platform before comes straight back.
Domains that come and go. Add domains in the console or from your server, cover subdomains with a verified wildcard, or let your server confirm new domains as people sign in.
No redirect at all, if you like. Chrome and Edge can show their own “Continue as” prompt on your page.
Passkeys, and roles and permissions in every token, on every domain.

Frequently asked questions

Can I share cookies between example.com and example.net?

No. Browsers send a cookie only to the domain that set it and, with the Domain attribute, to that domain’s subdomains. example.com and example.net are different sites, so each needs its own session, issued after one central sign-in.

Do subdomains count as different domains?

Not for cookies. A cookie set with Domain=example.com is sent to app.example.com and shop.example.com too. If all your sites are subdomains of one domain, a parent-domain cookie can be enough. As soon as you add a second domain, you need a central login.

Will people have to sign in again on my second domain?

Not with a central login. When they reach the second domain, it redirects them to the provider, which recognizes them from its own session and sends them back with a code. They see a quick redirect, not a form.

Does this still work when third-party cookies are blocked?

Yes. The redirect flow only uses first-party cookies: the provider reads its own cookie on its own domain, and your site sets its own cookie on yours. It doesn’t depend on iframes or third-party storage.

What happens when someone signs out?

Each site clears its own session. The provider’s session stays until it ends or the person signs out there, so they may come back without a form. If you want sign-out to end everything, also send the browser to the provider’s logout address.

Try loginos

loginos is an OpenID Connect provider that gives every domain of your product one shared sign-in:

Any number of domains, one user pool. Add them in the console or from your server, cover subdomains with a verified wildcard, or let your server approve new ones as people sign in.
Passkeys built in. Face ID, fingerprints and security keys, with passwords as a fallback, and no WebAuthn code in your app.
Roles and permissions in every token, the same on every domain.
Keep the users you have. People link their existing account once, and every token carries your own user id.
“Continue as” on your own page in Chrome and Edge, with a small loginos window everywhere else.
Standard OpenID Connect, so Auth.js, Passport or any OIDC library works. There are no paid plans today, and you can start without a card.

Create a platform in a few minutes, follow the quickstart, or read more answers like this one. This answer is kept up to date at loginos.io/answers.