Custom domains

Players can sign in on a hostname you own instead of the auth4.dev auth origin. You add a few DNS records, auth4.dev issues the certificate, and your project's issuer moves to your hostname.

Add a domain

1. Open Settings in a project and scroll to Custom domains.
2. Select Add domain and enter a subdomain you control, such aslogin.example.com.
3. At your DNS provider, create every record in the table the console shows: aCNAME that sends traffic to auth4.dev, a TXT record that proves you own the hostname, and a TXT record that lets the certificate be issued.
4. Select Check status. DNS changes can take a few minutes to be seen. When the status is Active, the console shows the hostname's issuer.

Owners and admins add and remove domains. Viewers can see them and their DNS records. A project can have up to 3 custom domains, and each hostname can belong to one project only.

Adding a hostname reserves it until it becomes active. If it hasn't become active 7 days after you added it, the reservation lapses: another project can add the hostname, and auth4.dev removes it from your project. Once a hostname has been active, it stays with your project until you remove it.

The hostname must be a subdomain: apex domains such as example.com aren't supported. IP addresses, private names such as .internal or .local, and auth4.dev hostnames are refused.

Statuses

A hostname serves sign-in only while it's active. auth4.dev decides which project a request belongs to from its own list of verified hostnames, never from the request alone.

Switch an app or game to the domain

Once the domain is active, your project has a second issuer:https://login.example.com/t/{projectId}. Tokens issued on the custom domain carry that issuer, so everything that talks to auth4.dev for an app must use the same one.

• Browser apps: set issuer in the browser SDK to the new issuer.
• Server APIs: set issuer in the server SDK to the issuer your clients use. Tokens from the other issuer are refused, so switch clients and servers together, or run a server check for each issuer during the change.
• Games: point device sign-in at the new issuer. The verification link players open then uses your hostname.

const auth4 = new Auth4BrowserClient({
  // Was https://auth.auth4.dev/t/{projectId}
  issuer: "https://login.example.com/t/{projectId}",
  clientId: "cli_…",
  redirectUri: "https://game.example.com/callback",
});

Players who already signed in keep their sessions on the issuer that created them. When an app switches issuer, its players sign in again.

Sign-in providers on your domain

• Discord, Steam, Google, Apple, Microsoft and Epic Games return players to your hostname. Add the callback URL with your hostname in place of auth.auth4.dev at each provider, for examplehttps://login.example.com/t/{projectId}/identity/discord/callback.
• For enterprise single sign-on, the SAML entity ID and ACS URL and the OIDC redirect URI also use your hostname. Give the organisation the values for the issuer its users sign in on.
• Passkeys belong to the hostname they were made on. A passkey made on the auth4.dev auth origin doesn't work on your domain, and the reverse. Players can still sign in with their other methods and add a passkey on the new hostname.
• Email magic links and device verification links sent from your domain open on your domain.

What runs on your domain

Your hostname serves hosted login, your project's discovery document and signing keys, and the OAuth and device endpoints, for your project only. The console and the management API stay on auth4.dev. Cookies set on your hostname are scoped to it alone.