Operationalization requires configuring or setting up infrastructure to support the scalable, measurable, and quantifiable operation that’s necessary for business continuity. In Auth0, this includes configuring supporting services (such as email providers), monitoring services for your deployment, detecting anomalous situations, and making preparations to recover quickly and smoothly when something goes wrong in a production environment.
Establishing effective operational behaviors is something that successful customers have found pays dividends, and there are a number of things you will want to consider when looking at your workflow:
What should you do to proactively detect failures?
How can you obtain data on Auth0’s operational status?
What should you do about Auth0 security bulletins related to the Auth0 service?
Does Auth0 provide information regarding impending changes in the Auth0 service?
How can you check for important notices from Auth0?
What should you do with Auth0 log data so that you can analyze it and keep it for longer than Auth0’s limited data retention period?
How can you scan Auth0 logs to determine if peak loads in your application trigger any rate limits or other errors?
What email services should you use to support production volumes of email messages to users? Can I use Auth0's out-of-box email provider in my production environment?
Do you need to configure your firewall and what firewall ports will you need to open for internal services that need to receive communications from Auth0 (such as custom databases, web services, and email servers)?
How will you provision new organizations?
Do you need to provide self-service provisioning for your customer so that they can configure their own organizational IdPs?
Auth0 supports functionality for monitoring Auth0 service operation as well as providing information regarding Auth0 service status. In addition, Auth0 makes security-related bulletins as well as information regarding upcoming changes to the Auth0 service available via various notifications. Auth0 logging services also provide extensive functionality for tracing and identifying operational anomalies, including restrictions encountered due to rate limiting and/or excessive loading.
Out-of-box, Auth0 provides email delivery services to help you accelerate your integration. These services, however, are not meant for scale-of-use in production environments, and do not provide for any specific service level or guarantee when it comes to email delivery. Our best practice recommendation, which customers typically follow, involves configuring your own email service provider.
You may also need to make changes to infrastructure configuration in order to support integration with Auth0 and to support use of Auth0 extensibility. For example, if you need to provide callbacks to your internal or even external infrastructure (e.g., if you need to make external API calls in Actions, Rules, or Hooks, or via custom database scripts if you need to leverage existing legacy identity storage), then you may need to configure your Firewall settings.
Once you know how you want organizations to be represented in your system, you will want too consider how you are going to provision the organization itself. See Provisioning organizations for more information.
In addition, many of our customers have developed one or more self-service portals for use by their customers' organization admins to provide self-service capabilities for configuring their own IdPs.
The Auth0 status dashboard together with the Auth0 uptime dashboard shows current and past status of the Auth0 service in a human-readable format. If any monitoring alerts are triggered, and as a first step in troubleshooting, your operations staff should check the status dashboard to see if there is a current outage. The public cloud status page also provides a facility for subscribing to outage notifications, and we also recommend that you check the status of any third-party external services you depend on, such as Social Providers. Having this information handy can help quickly eliminate possible causes when troubleshooting an issue and should be at the top of a troubleshooting checklist for developers as well as the help desk staff.
Information on how to check the status of Auth0 as well as any dependent services (such as Social Providers) should be at the top of a troubleshooting checklist for both developers and helpdesk staff, and we recommend you subscribe via the Auth0 status page to set up notification of any status updates.
In the event of an outage to the public cloud service, Auth0 performs a Root Cause Analysis (RCA) and publishes the results on the Auth0 status page. Auth0 performs a thorough investigation after an outage—including a determination of root cause, as well as contributing factors and how to prevent the issue from occurring again—and as a result, an RCA document can take a few weeks to be published.
Email provider setup
Auth0 sends emails to users for events such as signup welcome, email validation, breached password, and password reset events. You can customize the email templates for each type of event, and advanced customization of email handling is also possible. Auth0 provides a test email provider with limited capacity for basic testing, but you must set up your own email provider for production use, and customization of email templates will not work until you have established your own provider.
The default Auth0 email provider does not support sending production volumes of email or customization of email templates. You should therefore configure your own email provider before deploying to production.
If custom code executing in Auth0 (such as in an Action, Rule, Hook, or custom database scripts) will call a service inside your network, or if you configure an on-premise SMTP provider in Auth0, then you may need to configure your firewall to allow inbound traffic from Auth0. The IP addresses to allow through the firewall are specific to each region and are listed on the Rules, Hooks, custom database scripts, and email provider configuration screens in your Auth0 dashboard.
Auth0 provides extensive capability when it comes to the logging of events, and also in the scanning of logs in order to identify event anomalies (see logs documentation for further details). Standard log retention period for Auth0 logs is determined by subscription level with the shortest period being 2 days and the longest period being only 30 days. Leveraging Auth0 support for integrating with external logging services will allow you to retain logs outside of this, and will also provide for log aggregation across your organization.
You should leverage one of the Auth0 logs extensions to send log data to an external log analytics service. This will enable keeping data for longer periods of time and provide advanced analytics on the log data.
You should review the log data retention period for your subscription level, and implement a log data export extension to send log data to an external log analytics service. Development teams can use log files for troubleshooting and detecting intermittent errors that may be hard to find via QA tests. Security teams will probably want log data in case forensic data is ever needed. Exporting log files to services that provide comprehensive analytics can help you see patterns such as usage trends and attack protection triggers.
Rate limits and other errors
Auth0 provides a unique error code for errors reported when the rate limit is exceeded. You should set up automatic scanning of logs to check for rate limit errors so you can proactively address activity that hits rate limits before it causes too much trouble for your users. Auth0 also publishes error codes for other types of errors, and you will find it helpful to scan logs for authentication errors as well as errors from Auth0 Management API calls (Management API error codes are shown below each call in the Management API Explorer).
Calling the Management API to retrieve user profile information from within a Rule is a common cause of rate limit errors because such API calls can execute for every login as well as periodic session checks.
You should establish mechanisms for monitoring Auth0 implementations, so your support or operations team receives the timely information needed to proactively handle service outages. Auth0 provides monitoring endpoints that can be incorporated into your monitoring infrastructure. These endpoints are designed to provide a response suitable for consumption by monitoring services. It should be noted that they only provide data on Auth0. For complete end-to-end monitoring, which is essential for checking the ability of users to log in, we recommend that you set up synthetic transaction monitoring. This will provide greater granularity for your monitoring and enable you to detect outages unrelated to Auth0 as well as degradation of performance, so you can respond more proactively.
You should set up the ability to send synthetic login transactions to facilitate end-to-end monitoring of authentication. You can do this with a simple application that uses the Resource Owner Password Grant in combination with a test user that has no privileges, and don’t forget about Auth0 rate limiting policies too.
There are several different types of notifications from Auth0 that you should watch for as they contain important information that could impact your tenant(s) and project.
From time to time, Auth0 may send an important announcement related to your tenant. These announcements about your service will be sent to your Auth0 dashboard and depending on the severity of the announcement, via email to the registered Auth0 dashboard administrators. You should make a regular practice of logging in to the dashboard and checking the bell icon at the top for any important notices. In addition, you should review emails from Auth0 in a timely fashion as they may convey important information about changes or actions you need to take.
Auth0 security bulletins
Auth0 regularly conducts a number of security-related tests, and if any issues are found, will proactively identify and notify customers who need to make security-related changes. Due to the extensible nature of the Auth0 product, however, it may not be possible for Auth0 to identify every impacted customer, so you should regularly check Auth0 security bulletins.
It is a best practice to check the Auth0 Security Bulletins page periodically and take the recommended action if you are impacted by any security bulletins.
Auth0 provides information on changes to the service in the Auth0 change log. You should make a regular practice of reviewing Auth0 change logs to be aware of changes. Support teams researching an issue may find it useful to review the change log to determine if recent changes might be related, especially if these are breaking changes. Development teams will also want to review the change logs to identify new features that may be beneficial.
What you need to do when provisioning an organization will depend on how organizations are represented in your system. This can take some time to step back and consider how users of those organizations will be interacting with your applications. See Multiple Organization Architecture to determine how to configure organizations for your IAM system.
When provisioning organizations you need to consider the following:
You will need to add the organization to your own application configuration and/or database
You will need to make changes to your Auth0 configuration. This will include doing some or all of the following:
Create a unique tenant
Add a database connection (if you have isolated users per organization)
Add an enterprise connection for this organization
This will include working with the organization to either update their existing configuration or add configuration for your Auth0 tenant if they are not a legacy organization.
Provision an administrator for the organization
To avoid mistakes, you may want to create an Organization Admin Portal to make it easier to provision new organizations.
Organization Admin Portal
An organization admin portal is a portal that allows your administrators to create, modify, and remove organizations. There are multiple activities that need to be done both in your own system and your Auth0 tenant. This portal will likely need to exist in your own system so it has access to your datastores and configuration. However, Auth0 provides the Auth0 Management API so that you can incorporate changes to your Auth0 tenant at the same time that you create the changes in your own system.
There are two main approaches that can be taken for creating a new organization. The one you choose depends highly on your tolerance for how long it would take to deploy a new organization.
Live Updates to your Auth0 Tenant: If you want to be able to create new organizations in real-time, then you will likely want to make the changes directly to your Auth0 tenant using the Auth0 Management API. This allows the changes to take place in real-time and allow the addition of a new organization to take effect immediately.
Change the Repository and Re-deploy: If you are taking advantage of the Deploy CLI (or a custom CLI) as part of your CI/CD pipeline, you may prefer to push your changes directly to your repository and then kickoff a new deployment instead. This can take a little more time, but it has benefits associated with version history and the ability to backout a change by re-deploying the previous version.
You may want to have a separate repository just for the items that the organizations need so that you don't have to re-deploy other common components and risk making an error.
Self-Service IdP provisioning
While Auth0 connections make it easy to configure IdPs, it can be a time-consuming process to onboard customer organization IdPs especially if you are selling to new customer organizations on a regular basis or existing organizations have changing IdP requirements. As a result, many of our customers have found it worthwhile to build a self-service portal for their customers' organization admins so that they can configure their own IdPs. This cuts down on your IT department's workload. The Auth0 Management API provides all necessary connection management functionality to achieve this.
Project Planning Guide
We provide planning guidance in PDF format that you can download and refer to for details about our recommended strategies.
B2B IAM Project Planning Guide
Multiple Organization Architecture (Multitenancy)
Many B2B platforms implement some form of isolation and/or branding for their customers' organization, and this can add complexity to any Identity and Access Management (IAM) system. If this applies to you, then we recommend you take some time to read through our guidance and best practice advice for this type of environment.