General Usage and Operations Best Practices

Here are some recommended best practices for general Auth0 usage and operation.

Auth0 keeps tenant logs for a limited amount of time. (To learn more, read Logs.) To get log data and store it elsewhere, you can use the Auth0 Management API's Search log events endpoint, stream the logs to an external service, or export log events using one of the available extensions for services such as Loggly or Splunk.

Auth0 provides a test email provider, so you can test default welcome and email verification messages during tenant configuration. To learn more, read Email. The test provider can only send a limited amount of emails, so you should configure your own mail server. Additionally, we recommend a unique email provider account per tenant. Sharing an email account between tenants can be a potential source of problems or outages for one tenant when making changes to the service intended for another.

Also, make sure to configure and customize the templates for emails sent from Auth0. These include email verification messages, welcome messages, password reset messages, et cetera. For custom templates, provide a "from" address, a clear subject, your custom content, and a link timeout for emails with a link (such as a password reset link).

Sign up for notifications at the Auth0 status page. If there are any Auth0 outages, you or your support staff will be notified.

If you have custom code for Actions, Rules, Hooks, custom database scripts, or Webtasks, store it in a source code repository such as Github for version and audit control. Auth0 has extensions to help deploy code stored on external repositories. To learn more, read Auth0 Extensions.

If you have a full continuous integration/continuous deployment pipeline, use the Auth0 Deploy CLI tool for greater flexibility. To learn more, read Deploy CLI Tool.

If your Actions, Rules, Hooks, custom database scripts, or Webtasks require configuration values (such as credentials or API keys), you should store them in the Auth0 Dashboard. Storing configuration values in the Dashboard makes migrating configuration between tenants easier. To learn more, read Set Up Multiple Environments.

If your Actions, Rules, Hooks, custom database scripts, or Webtasks call a service in your intranet or behind another firewall, be sure to add the Auth0 public IP addresses to the AllowList. This lets requests from those IP addresses through. You can find the IP addresses for each region in your Auth0 Dashboard, where you edit rules, hooks, or custom database scripts.

The Auth0 Support Center provides a configuration checker tool. Run the configuration checker periodically during development and again before you launch.

To run the configuration check, go to Auth0 Support Center > Tenants, select the gear icon, and choose Run Production Check.

Avoid pinning or fingerprinting TLS certificates used on Auth0 API endpoints. Certificates presented on Auth0 endpoints are issued for varying expiry timeframes. These certificates are renewed with different intermediate certificate authorities and root certificate authorities. Any sort of pinning or fingerprinting should be avoided since any aspect of the certificate chain can be changed at any time. Pinning and fingerprinting any certificates in the chain and using this uniquely identifying information can lead to unexpected behaviors within your applications or services.