Custom domains for CIAM: do's and don'ts
Updated 2026-05-07
Custom domains are the deployment-level decision that touches branding, security, and the architecture of WebAuthn. The do's and don'ts here apply equally to greenfield deployments choosing the auth domain and to existing deployments planning a migration to a different scheme.
For broader CIAM deployment patterns, see the B2B SaaS identity guide and the WebAuthn explained guide.
Do
Use a custom domain (auth.example.com or login.example.com) for CIAM
Default CIAM-vendor domains (auth0.example.com.au0.com or similar) leak vendor information to users, weaken brand trust, and create a phishing surface. A custom domain makes the auth flow look native to the application.
Major B2C apps (Netflix, Spotify, Amazon) all use custom-domain auth. Brand consistency studies and conversion-rate research consistently show custom-domain auth converts higher than vendor-domain redirects at registration.
Set the WebAuthn RP-ID to the apex domain, not the auth subdomain
RP-ID determines which domains can use a passkey. If RP-ID is auth.example.com, the passkey only works at auth.example.com. If RP-ID is example.com (the apex), the passkey works at app.example.com, dashboard.example.com, and any other subdomain.
W3C WebAuthn specification 13.4.7. Production deployments routinely fail when teams set RP-ID to a specific subdomain and later try to use passkeys at sibling subdomains.
Manage SSL certificates via the CIAM vendor's automation
Self-managed SSL on the auth subdomain is operational toil that the CIAM should automate. Most modern CIAM ship custom-domain support with automatic Let's Encrypt or vendor-managed certificates that renew without intervention.
Auth0, Stytch, Clerk, WorkOS, MojoAuth, and most others ship custom domain with automatic certificate management as a standard feature.
Pre-warm DNS and certificate before launch
DNS propagation and certificate issuance can take 30 minutes to several hours. Provisioning the custom domain a day before launch avoids the failure case where the auth flow is broken for a fraction of users while DNS catches up.
Standard SRE practice. Major CIAM vendors document the pre-launch checklist; Auth0's custom domain documentation explicitly warns about TTL and propagation timing.
Don't
Don't use a CIAM-vendor subdomain for production B2C auth
yourapp.us.auth0.com or yourapp-staging.firebaseapp.com is fine for development; in production it leaks vendor information and undermines the user's trust signal at the auth boundary.
Brand consistency research and security UX studies consistently show users develop weaker trust at auth flows on third-party domains. Documented phishing campaigns specifically impersonate legitimate apps using look-alike vendor subdomains.
Don't set RP-ID to a subdomain unless you have a specific reason
Subdomain-scoped RP-IDs lock passkeys to that subdomain. Sites that grow to multiple subdomains discover months later that passkeys don't work across them. The default should be the apex domain.
The W3C spec permits subdomain RP-IDs but in practice the apex is correct for nearly all deployments. Production CIAM incidents have traced to subdomain-scoped RP-IDs that locked out passkeys after architecture changes.
Don't use HTTP for the auth subdomain, even temporarily
WebAuthn requires HTTPS. Cookies should be Secure. Tokens leak in plaintext over HTTP. There is no legitimate reason to expose CIAM over HTTP in 2026, including in staging.
WebAuthn Level 3 specification mandates secure context. OAuth 2.1 forbids tokens in URL or non-HTTPS transport. Browser console warnings on insecure auth flows make any HTTP exposure obvious.
Don't share the auth subdomain across non-trusted applications
Cookies scoped to .example.com are sent to every subdomain. If staging.example.com or feature-branch.example.com is less trusted than auth.example.com, an attacker who compromises the lesser subdomain reads the cookies the user holds for auth.
Cross-subdomain cookie attacks have caused real production incidents at multiple SaaS vendors. Scope cookies as narrowly as the application requires; segregate untrusted subdomains to a different parent domain.