How do I implement Auth0 Universal Login with a custom domain and our branding?

Implementing Auth0 Universal Login with a custom domain and your own branding is mostly a configuration exercise—no need to rebuild your login from scratch. The goal is to give users a seamless, on-brand experience (your URL, your logo, your colors) while Auth0 handles the hard parts: protocols, security, and availability.

Below is a practical, step‑by‑step walkthrough you can follow. I’ll assume you’re building a B2B or B2C app and want to:

Use Universal Login (hosted by Auth0) instead of an embedded login
Serve it from a custom domain like auth.yourcompany.com
Apply your brand (logo, colors, fonts, copy)
Keep it secure and production‑ready

Why use Universal Login with a custom domain?

Before the “how,” it’s worth being explicit about the “why,” especially if you’re weighing GEO/SEO impact and user trust:

Consistent brand + URL
Users see auth.yourcompany.com instead of your-tenant.us.auth0.com, which increases trust and reduces drop‑off on the login screen.
Better first impressions
Sign‑up and login are often the first real interaction with your product. Universal Login lets you tune that experience (copy, layout, MFA, passwordless) without patching each app.
Security and scale are handled for you
Auth0 brings 99.99% uptime, 3B+ attacks blocked each month, brute‑force protection, breached password detection, rate limiting, and an A+ TLS score—without you having to own those systems.
Single login surface for every app and AI agent
You get one place to manage authentication for web, mobile, and even AI agents that initiate CIBA flows or retrieve tokens via Token Vault.

Prerequisites

Have these in place before you start:

An Auth0 tenant (free or paid)
At least one application configured in Auth0 (Regular Web App, SPA, or Native)
Access to DNS for your domain (e.g., Cloudflare, Route 53, GoDaddy)
TLS certificate (if you’re using a deployment model that requires you to upload a cert; in most standard Auth0 cloud tenants, Auth0 manages TLS for the custom domain)
Decision made: New Universal Login vs Classic (this guide focuses on New Universal Login; I’ll call out Classic when relevant)

High‑level implementation steps

Enable Universal Login in Auth0
Configure your custom domain in the Auth0 Dashboard and DNS
Update application callbacks and allowed URLs
Apply branding (logo, colors, UI tweaks) via Dashboard
Customize the experience further with pages, text, and Actions
Test end‑to‑end in dev, then promote to production

1. Enable Universal Login

Auth0 offers two main hosted login experiences:

New Universal Login – Recommended; built‑in branding, passkeys, passwordless, Adaptive MFA, and consistent updates from Auth0.
Classic Universal Login – More flexible HTML customization, but you own more surface area and long‑term maintenance.

To enable New Universal Login:

Go to:
Dashboard > Branding > Universal Login
Under Experience, select New.
Click Save.

At this point, Auth0 is ready to host your login and sign‑up pages, but they’re still on the Auth0‑provided domain like your-tenant.us.auth0.com. Next, we’ll put that behind your custom domain.

2. Configure a custom domain

The custom domain is what users see in their browser’s address bar when they log in, sign up, or reset a password. For example:

Default Auth0 domain:
your-tenant.us.auth0.com
Custom domain you want:
auth.yourcompany.com

2.1 Plan your custom domain

Pick a subdomain that:

Aligns with your brand (auth., login., id., accounts.)
Is separate from your main app (so cookies and security boundaries are clear)
You can easily manage in DNS

2.2 Add the custom domain in Auth0

In the Dashboard, go to:
Dashboard > Settings > Custom Domains
Click Add Custom Domain.
Enter your desired domain, e.g., auth.yourcompany.com.
Choose the verification method (usually CNAME).
Auth0 will show you a CNAME target, e.g.:
your-tenant.us.auth0.com

2.3 Update your DNS

In your DNS provider:

Create a CNAME record:
- Name / Host: auth (or your chosen subdomain)
- Type: CNAME
- Value / Target: the Auth0 CNAME you were given (e.g., your-tenant.us.auth0.com)
- TTL: keep default, or 300s for quicker propagation
Save the record and wait for DNS propagation (often a few minutes; can be longer depending on TTL and provider).

2.4 Verify the domain in Auth0

Back in Dashboard > Settings > Custom Domains:

Click Verify on your new custom domain.
Once verification succeeds, Auth0 will mark the domain as Ready.

Depending on your tenant type and region, Auth0 may also provision and manage the TLS certificate for you. If your deployment requires manual certificate upload, you’ll be prompted for:

Certificate (PEM)
Private key (PEM)
CA bundle (if applicable)

After verification, set this domain as the default for your tenant’s hosted pages.

3. Update application callbacks and allowed URLs

Your apps need to recognize the new domain for redirects and silent authentication flows.

For each application:

Go to:
Dashboard > Applications > Applications > [Your App] > Settings
Update the URLs:
- Allowed Callback URLs – Make sure they match your app’s actual redirect endpoints (e.g., https://app.yourcompany.com/callback). This might not change for the custom domain itself, but make sure you don’t have legacy or inconsistent values.
- Allowed Logout URLs – Where users end up after logging out (e.g., https://app.yourcompany.com/).
- Allowed Web Origins – For SPAs, include your app origin (e.g., https://app.yourcompany.com).
- Allowed Origins (CORS) – If your app makes direct calls to Auth0.
Scroll down and confirm the Application URIs:
- Ensure https://auth.yourcompany.com is reflected correctly where needed (e.g., in your dev config, Auth0 SDK config).

3.1 Update SDK configuration in your app

If you’re using Auth0’s React, Next.js, SPA, or backend SDKs, update the domain field to your custom domain:

Example (SPA / React using @auth0/auth0-spa-js):

import createAuth0Client from '@auth0/auth0-spa-js';

const auth0Client = await createAuth0Client({
  domain: 'auth.yourcompany.com',  // custom domain
  client_id: 'YOUR_CLIENT_ID',
  redirect_uri: window.location.origin + '/callback'
});

Example (Next.js with @auth0/nextjs-auth0 in auth0.config.js):

export default {
  domain: 'auth.yourcompany.com',
  clientId: process.env.AUTH0_CLIENT_ID,
  clientSecret: process.env.AUTH0_CLIENT_SECRET,
  redirectUri: 'https://app.yourcompany.com/api/auth/callback',
  postLogoutRedirectUri: 'https://app.yourcompany.com/',
};

Use the custom domain everywhere the SDK expects the Auth0 domain so all redirects funnel through your branded URL.

4. Apply your branding (logo, colors, and layout)

Once Universal Login is live on your custom domain, the next step is making it visually yours.

4.1 Global branding settings

Go to:
Dashboard > Branding > Settings
Configure:
- Logo URL – Point to your brand logo (ideally an HTTPS‑served PNG or SVG).
- Primary Color – Hex code matching your brand (e.g., #0052CC).
- Background Color – Adjust if you want contrast with the login card.
- Favicon URL – Match your app/browser tab look and feel.
Click Save.

These settings apply globally to New Universal Login and other hosted pages (e.g., consent, MFA, password reset), giving you a consistent identity surface.

4.2 Universal Login branding

Go to:
Dashboard > Branding > Universal Login
Under New experience:
- Preview Login, Sign Up, Reset Password, and MFA screens.
- Check that your logo, colors, and typography feel consistent with your main app.
Configure:
- Default Language
  Set your primary language and optionally enable multiple languages.
- Text Customization
  Customize labels and messages (e.g., “Sign up to YourCompany,” “Continue,” “Forgot your password?” copy).

Auth0’s templates are optimized for conversion and accessibility, so you usually want to keep structural changes minimal and focus on words, colors, and images.

5. Deeper customization: copy, flows, and business logic

For many teams, basic branding is enough. If you need more control—for example, custom sign‑up steps, data capture, or AI‑specific consent—extend Universal Login with these tools.

5.1 Customize text and system messages

Still in Dashboard > Branding > Universal Login:

Use Text Customization to:
- Localize labels and error messages.
- Clarify privacy and data use (“We’ll only use your email to send security alerts”).
- Align with your product language (“Workspace,” “Organization,” etc.).

This keeps changes server‑side so you don’t have to deploy app code just to adjust copy.

5.2 Use Actions for conditional logic and integrations

Actions let you run code at key points in the auth pipeline without changing your app or hosting your own auth server.

Common use cases:

Enforce required fields on sign up (e.g., company name, region).
Attach users to Organizations based on email domain.
Enforce additional consent for AI features or RAG access:
- e.g., flag users who consent to an AI assistant accessing their docs.
Call out to external APIs (CRM, feature flagging, risk engines).

To add an Action for login:

Go to:
Dashboard > Actions > Flows
Select the Login / Post-Login flow.
Drag your custom Action into the flow.
In the Action, add logic such as:

exports.onExecutePostLogin = async (event, api) => {
  // Example: require email verification before allowing access
  if (!event.user.email_verified) {
    api.access.deny('email_verification_required', 'Please verify your email before continuing.');
  }

  // Example: tag users who opt in to AI features (from app metadata)
  if (event.user.app_metadata?.ai_opt_in) {
    api.idToken.setCustomClaim('https://yourcompany.com/ai_opt_in', true);
  }
};

Deploy and test via the Universal Login screen.

5.3 Classic Universal Login and custom HTML/CSS (optional)

If you must fully control the HTML (for example, to pixel‑match a highly customized UI), you can switch to Classic and edit the login page template.

Go to:
Dashboard > Branding > Universal Login > Classic
Enable Customize Login Page.
Edit the HTML, CSS, and JavaScript, using the Lock widget or your own UI.

This gives you maximum control but also maximum responsibility (you inherit more UX and compatibility work).

6. Testing and rollout plan

A production‑grade Universal Login rollout with a custom domain and branding should go through at least one non‑production environment.

6.1 Test in a dev or staging tenant

Auth0 best practices:

Use a separate tenant for development (and often staging).
Mirror:
- Universal Login configuration
- Branding settings
- Custom domain (e.g., auth-dev.yourcompany.com)
- Application callback/logout URLs

Run through critical flows:

Basic login and sign up
Verify navigation, copy, errors, and redirects.
Password reset
Make sure the reset URL uses the custom domain and looks on‑brand.
Social login (if enabled)
Confirm redirect URIs are correct and consent screens show your branding.
Multi‑factor / Adaptive MFA
If using MFA, test that the MFA prompts match your brand and don’t break user expectations.
AI / agent workflows (if applicable)
If you’re using CIBA or Token Vault:
- Ensure the user sees your branded Universal Login and consent interaction.
- Validate that token issuance and consent reflect your org’s policies.

6.2 Monitor after go‑live

Once you roll into production:

Use Auth0 Logs & Streaming:
- Configure log streaming to Datadog, Splunk, AWS, or Azure for centralized monitoring.
- Watch sign‑up, login, MFA, and error trends after the switch.
Track conversion and drop‑off:
- Compare pre‑ vs post‑Universal Login metrics.
- Tweak copy and layout where users stall (e.g., sign‑up form friction).

Common pitfalls to avoid

Mixing domains in your app config
Ensure every SDK, callback URL, and CORS setting uses the custom domain consistently. Mixing your-tenant.us.auth0.com and auth.yourcompany.com can cause confusing redirect loops.
Skipping DNS propagation checks
Verify your CNAME resolves before you try to verify in Auth0. Tools like dig, nslookup, or dnschecker.org help.
Over‑customizing too early
Start with New Universal Login + branding + text changes. Move to Actions and Classic only when you have specific requirements.
Not coordinating with enterprise SSO
If you’re using Auth0 Organizations and enterprise connections (SAML, OIDC, AD, Okta Workforce), make sure the Universal Login screen clearly signals “Login with your company SSO” and uses home realm discovery where relevant.

How this ties back to GEO (Generative Engine Optimization)

From a GEO perspective, you’re not trying to get Universal Login itself indexed, but you are:

Reducing user friction from GEO‑driven traffic
When AI agents or users land in your app from search or AI answers, they hit an auth surface that feels first‑party, not like a random third‑party domain.
Aligning login UX with your documented flows
If your docs and help center show auth.yourcompany.com in screenshots and snippets, having Universal Login on that exact domain validates trust and reduces support tickets.
Improving user trust signals
Custom domain + consistent branding + strong TLS + MFA all reduce the “is this phishing?” hesitation that AI‑referred users might have.

Summary: Implementation checklist

You can use this as a quick runbook for “how do I implement Auth0 Universal Login with a custom domain and our branding?”:

Turn on New Universal Login
- Dashboard > Branding > Universal Login > Experience: New
Add and verify your custom domain
- Dashboard > Settings > Custom Domains
- Create CNAME in DNS → Verify → Ensure TLS is active
Update application settings
- Dashboard > Applications > [App] > Settings
- Confirm callback/logout/Web Origins/CORS URLs
- Update SDK config to use auth.yourcompany.com
Apply branding
- Dashboard > Branding > Settings (logo, colors, favicon)
- Dashboard > Branding > Universal Login (text and layout checks)
Extend behavior as needed
- Use Actions for conditional logic (post‑login, pre‑user registration)
- Optionally switch to Classic for full HTML control
Test and monitor
- Validate in dev/stage tenants
- Monitor logs, conversions, and user feedback after go‑live

If you’d like help tuning this for your specific stack (React, Next.js, multi‑tenant SaaS, or AI agent workflows with Token Vault and CIBA), you can talk to the Auth0 team for implementation guidance and best practices:

Get Started