Auth0 custom domain: setup, Google sign-in and troubleshooting

Why Google shows auth0.com

Auth0's Google connection sends users back to https://{yourDomain}/login/callback, and {yourDomain} is your tenant domain until you add a custom domain. Google's branding help says that until an app's branding passes Google's verification, "only your application domain will be visible to users". With Auth0 in the middle, the domain users see is typically the tenant domain, for example "continue to your-tenant.us.auth0.com". Once a custom domain is set up and the Google connection and redirect URI use it, users should see your domain instead (or your app name, if your Google branding has passed verification).

Before you start

• Plan and billing. Auth0's docs state that a tenant needs a valid credit card on file to set up a free custom domain (the card is not charged). Self-managed certificates require an Auth0 Enterprise subscription.
• One domain per tenant with Auth0-managed certificates.
• Pick the domain. Most guides, including this one, use a subdomain you don't use for anything else, such as login.example.com. If you plan to use passkeys, read Auth0's custom domains overview first: it recommends the root domain in that case, because passkeys are bound to the domain.
• Own Google keys. Auth0 developer keys can't be used with custom domains, so create a Google OAuth client first (see below).
• Users get signed out. Existing sessions become invalid after the switch, and Auth0 notes users may need to clear the cookie if they see login errors.

Option A: Auth0-managed certificate (most setups)

Auth0 issues and renews the certificate (every three months) as long as your DNS record stays in place.

1. In the Auth0 Dashboard, open Branding → Custom Domains (some tenants show Settings → Custom Domains; as of Oct 2026).
2. Enter login.example.com, choose Auth0-managed certificates, and select Add Domain.
3. Copy the CNAME value Auth0 shows and create this record at your DNS provider:

Type:  CNAME
Name:  login.example.com   (often just "login" in the DNS UI)
Value: <the value shown in the Auth0 Dashboard>
TTL:   default

4. Back in Auth0, select Verify. It can take a few minutes depending on your DNS; once it succeeds, the domain should be ready within 1 to 2 minutes.

Cloudflare DNS: set this record to DNS only (gray cloud), not Proxied (orange cloud). Auth0 support states a proxy is not supported with Auth0-managed certificates, and a proxied record can keep the domain in Pending Verification indefinitely. Auth0 also recommends turning off CNAME flattening; it is unsupported for Auth0-managed certificates.

Option B: Self-managed certificate behind Cloudflare (Enterprise)

Use this only if you must keep the Cloudflare proxy on.

1. In Branding → Custom Domains, add the domain with Self-managed certificates (as of Oct 2026).
2. Add the TXT record Auth0 shows, then select Verify. If it isn't done within three days, repeat the steps.
3. Save the Origin Domain Name (like {yourTenant}-<CUSTOM_DOMAIN_ID>.edge.tenants.us.auth0.com) and the cname-api-key. Auth0 shows the key only once.
4. In Cloudflare (the custom domain must not already exist in the zone): - CNAME login.example.com → the Origin Domain Name, Proxied. - A Page Rule on the custom domain with Host Header Override = Origin Domain Name and True-Client-IP enabled. Auth0's recommended approach needs a Cloudflare Enterprise plan for these features. - A Transform Rule (Modify Request Header) that sets a static header cname-api-key to your key, scoped to the custom domain hostname. - Always Use HTTPS on and SSL/TLS mode Full or stricter. The proxy must use TLS 1.2 or newer.
5. Tell Auth0 which header carries the visitor IP:

curl -X PATCH "https://<tenant>.us.auth0.com/api/v2/custom-domains/<CUSTOM_DOMAIN_ID>" \
  -H "Authorization: Bearer <MANAGEMENT_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{ "custom_client_ip_header": "true-client-ip" }'

The Management API reference for this call is "Update custom domain configuration". Test this proxy setup on a staging tenant before relying on it.

Auth0's guide notes Cloudflare Workers can replace the Page and Transform rules, but recommends the rules because they need no custom code. If you add Managed Challenges, keep them off /oauth/token, /api/v2/* and /samlp/*.

Point Google sign-in at the custom domain

1. Google Cloud (as of Oct 2026): Google Auth Platform → Clients → create or open a Web application client and set:

Authorized JavaScript origins:  https://login.example.com
Authorized redirect URIs:       https://login.example.com/login/callback

You can keep the tenant-domain URI (https://<tenant>.us.auth0.com/login/callback) during the switch so apps still on the old domain keep working. Google says changes can take 5 minutes to a few hours to take effect.

2. Auth0 (as of Oct 2026): Authentication → Social → Google / Gmail, paste your own Client ID and Client Secret instead of developer keys, save, and use Try Connection.

3. Your app: initialize the SDK with the custom domain, not the tenant domain:

# @auth0/nextjs-auth0 v4 (.env.local)
AUTH0_DOMAIN=login.example.com

// @auth0/auth0-spa-js
import { createAuth0Client } from "@auth0/auth0-spa-js"

const auth0 = await createAuth0Client({
  domain: "login.example.com",
  clientId: "<AUTH0_CLIENT_ID>",
  authorizationParams: { redirect_uri: window.location.origin },
})

4. Your APIs: tokens carry the iss of the domain used to get them, so validate the issuer as https://login.example.com/. The audience doesn't change, and Auth0's own APIs such as /api/v2/ keep the tenant domain as audience.

If you use a customized Universal Login page with Lock or Auth0.js, it also needs the configurationBaseUrl / overrides settings described in Auth0's custom domain feature guide.

Custom domain not working: troubleshooting

To read the current state, run auth0 domains list (Auth0 CLI) or call GET /api/v2/custom-domains and check status, verification.status and certificate.status.

How to confirm it worked

• The custom domain shows as ready in Branding → Custom Domains.
• Clicking "Log in" in your app opens https://login.example.com/authorize?..., not the tenant domain.
• Google's sign-in screen names login.example.com (or your app name) instead of the tenant domain.
• An ID token from a test login has "iss": "https://login.example.com/".

Related guides: Change the app name on Google sign-in · Google OAuth consent screen · redirect_uri_mismatch explained