By default, every Auth0 tenant on the US cluster shares a subdomain under us.auth0.com. Your app's login page lives at something like yourapp.us.auth0.com. So does every other Auth0-powered app on the same cluster.
Password managers key credentials to domains, not apps. When a user logs into your app and later logs into an unrelated app that also uses Auth0, their password manager sees the same domain and offers credentials from both apps interchangeably. On iOS, iCloud Keychain surfaces suggestions from every Auth0 app the user has ever touched. The user sees a dropdown full of unrecognized credentials and has to dig through them to find the right one.
This is a real UX problem, and it compounds over time as Auth0's market share grows. The fix is to give your tenant its own domain.
Setting Up the Custom Domain
Auth0 supports custom domains on Professional and Enterprise plans. The setup is in the dashboard under Branding > Custom Domains.
Add your subdomain. auth.yourdomain.com is the conventional choice. Auth0 generates a CNAME record that you add through your DNS provider. The record looks like this:
auth.yourdomain.com CNAME <value>.edge.tenants.auth0.com
The exact target value comes from the Auth0 dashboard after you add the domain. Once DNS propagates (typically a few minutes to a few hours depending on your TTL), Auth0 verifies ownership and issues a TLS certificate automatically. You don't manage the certificate.
After verification, update your SDK initialization to use the custom domain:
// Before
Auth0
.authentication(clientId: clientId, domain: "yourapp.us.auth0.com")
// After
Auth0
.authentication(clientId: clientId, domain: "auth.yourapp.com")
The tenant still runs on Auth0's infrastructure. You're giving it a branded front door.
iOS: Making iCloud Keychain Work
A custom domain improves password manager behavior by default because credentials now key to auth.yourdomain.com rather than the shared subdomain. On iOS you can go further: wire up Associated Domains so iCloud Keychain treats your custom login domain as belonging to your app. This enables the credential suggestion sheet that appears in ASWebAuthenticationSession to surface the right credentials with your app's icon.
Configure Auth0 to serve the AASA file
Open your application in the Auth0 Dashboard and navigate to Advanced Settings > Device Settings. Enter your Apple Team ID and your app's Bundle ID (the App ID). Auth0 generates an Apple App Site Association file and serves it at the well-known path on your custom domain.
After saving, verify that the CDN has picked up the file:
https://app-site-association.cdn-apple.com/a/v1/auth.yourdomain.com
The Apple CDN caches this file. A valid response includes a webcredentials entry with your app's App ID. That's the signal that the association is in place.
Add the entitlement to your app
In your app's entitlements file, add your custom domain to the Associated Domains list:
<key>com.apple.developer.associated-domains</key>
<array>
<string>webcredentials:auth.yourdomain.com</string>
</array>
If you're already using Associated Domains for Universal Links, add this entry alongside your existing entries. Each domain gets its own entry.
Verify on device
Install the app on a physical device with iCloud Keychain enabled. When you open the login sheet, iCloud Keychain should offer credentials scoped to your app. If you want to inspect the association directly, check Settings > Passwords on iOS and confirm that credentials saved to auth.yourdomain.com show your app's icon.
Known issue with Flutter and Apple CDN caching
If you're using auth0-flutter, there's a known AASA caching issue (auth0-flutter #430). The Apple CDN sometimes caches an AASA file format that doesn't match what the package expects, causing the webcredentials lookup to fail silently.
The caching is on Apple's side. The fix is to wait: the CDN typically refreshes within 24-48 hours after Auth0 generates a valid file. You can check the current CDN state with the verification URL above. If the CDN returns a valid AASA but on-device testing still fails, try deleting and reinstalling the app to clear the device-side cache.
Android: Digital Asset Links
Android's equivalent of Associated Domains is Digital Asset Links. The mechanism is similar: Auth0 serves a JSON file at a well-known path, your app declares the association, and credential managers use the file to scope suggestions to your app rather than the shared Auth0 domain.
Configure Auth0 to serve the assetlinks.json file
In the same Device Settings section, find the Android configuration. Enter your app's package name (e.g., com.yourapp.app) and the SHA-256 fingerprint of your signing certificate.
You can get the fingerprint from your keystore:
keytool -list -v -keystore your-release-key.jks -alias your-key-alias
If you want autofill to work during development as well as in production, add both your release and debug fingerprints. The debug keystore is typically at ~/.android/debug.keystore with alias androiddebugkey and password android:
keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android
Auth0 generates the Digital Asset Links file and serves it at https://auth.yourdomain.com/.well-known/assetlinks.json.
Verify the association
Google provides a verification endpoint:
https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://auth.yourdomain.com&relation=delegate_permission/common.handle_all_urls
A successful response lists your app's package name and confirms the association is valid. If your package name and fingerprint are present in the response, credential managers can associate logins with your app.
Test credential autofill
With the association in place, Android credential managers (Google Password Manager, 1Password, Samsung Pass) associate credentials saved on auth.yourdomain.com with your app's package. On the login screen, your credential manager should offer suggestions scoped to your app rather than all Auth0-powered apps on the device.
What Happens to Existing Users
If you're adding a custom domain to an existing app where users have already saved credentials to the old us.auth0.com subdomain, those saved credentials won't automatically migrate. Users will need to save them again to the new domain.
For most apps this is low friction: the user logs in once with their existing credentials, their password manager offers to save them to the new domain, and they're set. If you want to reduce any confusion, a brief mention in your release notes or a login-screen prompt can guide users through it.
The underlying Auth0 account is the same tenant. User records, roles, and application configuration carry over. Only the login domain changes.
Branding
The functional improvements are the reason to do this, but there's a secondary benefit: users see auth.yourdomain.com in the browser bar during login rather than something.us.auth0.com. For anyone paying attention, your domain in the URL bar during authentication is a small trust signal. It also means your login flow doesn't advertise your infrastructure vendor.
Summary
The credential isolation problem is easy to overlook in development because developers typically have a single Auth0-powered app installed. Users in the real world often don't. A custom domain makes your login page a first-class part of your domain rather than a subtenant of a shared platform.
The setup is dashboard-driven. You're configuring a CNAME, entering a Team ID and Bundle ID for iOS, entering a package name and fingerprint for Android, and flipping the domain in your SDK initialization. Auth0 handles the TLS certificate, the AASA file, and the assetlinks.json file automatically once you've provided the identifying information.
If you're building a mobile app on Auth0, this is worth completing before your first public release. Credential associations form when users first save passwords. Starting with the right domain means users build the right habits from the beginning, and you avoid the migration friction later.