Last Updated Aug 28, 2024
Overview
A Custom Domain has been set up. However, applications and login flows are still using the old Canonical Domain.
Cause
Enabling a Custom Domain does not automatically replace the previous Canonical Domain. A Custom Domain adds a new, branded, option that can be used to provide a more seamless flow to the end user. However, it will need to be manually configured on the applications that want to provide the Custom Domain experience.
Solution
To configure Auth0 features to use the Custom Domain, it is needed to complete additional steps depending on the features in use. For example, if an application is configured to initiate a login flow using the Canonical Domain, the code in charge of starting the login request should be updated to use the new Custom Domain.
If an existing application starts the login flow by calling the Authorize endpoint:
https://canonical-domain/authorize?
client_id=clientid&
redirect_uri=https://allowedcallbackurl.com&
audience=https://intended-audience
...
...
It should be updated to use the new Custom Domain:
https://NEW-CUSTOM-DOMAIN/authorize?
client_id=clientid&
redirect_uri=https://allowedcallbackurl.com&
audience=https://intended-audience
...
...
These changes may also include VPNs, Firewalls, Emails, etc.
Also, note that existing sessions created at the Canonical Domain will no longer be valid once trying to use the custom domain, so users will have to log in again.
Lastly, take into account that a Custom Domain will not disable Auth0’s Canonical Domain. Users will be able to use either the Canonical or Custom domain according to what is configured on the application.
A list and instructions on how to configure features to use Custom Domains can be found in: Configure Features to Use Custom Domains