Custom Domain Best Practices - Architecture and Testing Questions

Help
1

We are looking for some best practices for creating an Auth0 ‘custom domain’ architecture,.

We don’t want to burn too many cycles in trial and error hoping to land the correct architecture.

Here’s what we have and are looking to accomplish with our current project:

So basically using an angular and html architecture we have two components: a basic site which is simple static HTML that provides info about our products/services, etc, a SaaS product with a login (i.e.: paywall) which customers use and is based on angular architecture which users must log in to in order to access/use.

When creating an Auth0 custom domain (yes, we’ve read the docs),…
The docs use an example URL for the custom domain of login.northwind.com, so in relation to our example above it suggests we use “https://login.oursite.com”…

Here’s what we’re not sure of with Auth0 Custom Domain architecture and best practice(Any answers to these questions, greatly appreciated):

  • Does the custom domain name need to match the application site sub domain name (not TLD domain)? That is, would login.oursite.com be then only a one time user access page for logging in based on the universal login, or can custom domain also be the sub-domain of the application, i.e.: app.oursite.com? Does this mean that regardless of sub-domain, as long as the Auth0 custom domain is on the same TLD domain (i.e.: oursite.com) then all response and requests are safely handled per normal?
  • Will the custom domain change the reference that users see when using using social login? For example, when using Google Auth, using universal login, the user is prompted to allow “Auth0” to access email, name, etc. as part of the handshake. But, Will the custom domain configuration in Auth0 change this for google auth to state, “oursite.com” wants access to your email, name, etc., instead?
  • Is there a way and what is the best practice for testing a custom domain locally? If our developers are developing on local workstations, and we implement custom domain, will a callback to localhost:3000, for example still work to receive callback details, etc. for local testing? If not, what is the best way to test custom domain is working or must one always deploy to a public domain to test?

Any help on the above questions would be greatly appreciated.

Thanks in advance.

2

The custom domain you select will be used as means to represent/access your Auth0 service HTTP endpoints. This means that in general, you will want to select a subdomain of your own domain as login/access management will be just a part of your online presence so you will usually want to reserve the parent domain for a landing page or marketing site. Due to the above, a usual selection for custom domain will be login.[yourdomain].

In terms of your specific points; the custom domain will be directly associated with only the endpoints for login so you will need to use a (sub)domain different than the one you want for the application. Following your example, the custom domain would be login.oursite.com and the application would be accessible at app.oursite.com.

Technically the custom domain could even be located in a totally different parent domain login.example.com, however, if the application and custom domain share a TLD+1 (in this case, share oursite.com you have less to worry about in terms of possible implications around the browser concept of third-party cookies).

If you use a custom domain certain social providers like Google will indeed surface the parent domain of the redirect URI which will mean the user will be less confused.

In order to configure/verify a custom domain you will need to own a certain domain so that you can manage the corresponding DNS, however, application development won’t be impacted and you can still develop (applications) using localhost as long as configuration in Auth0 allow to use localhost in callback URL’s.

3

Super helpful. Thank you for responding. I would like to hear if you have any feedback on the local testing question.

4

For local development, the use or not use of a custom domain should be irrelevant and you can continue to use callbacks to localhost. The local machine will need internet access in order to access the tenant (either default domain or custom domain), but the processing of callbacks continues to be through redirects so the use of a custom domain should not cause any major changes to local development.

1 Like