Performance Best Practices
Rules execute as part of a pipeline where artifacts for authenticity are generated, as described in Anatomy Best Practices. As such, an enabled rule will execute for every login operation (interactive or otherwise), every silent authentication, and every time a user-credentials-related Access Token is generated for an API call. This means that even in small scale deployments, performance can be a concern, which will only be exacerbated as the scale of deployment increases.
Avoid unnecessary execution
Prefer to implement execution based on conditional logic. For example, to run a rule for only specific applications, check on a specific
clientID or for specific
clientMetadata—especially when checking against a single
clientMetadata value, common across multiple applications. Using
clientMetadata can also make adding new clients (as well as reading rule code) easier, especially if you have a large number of applications defined, by reducing the code changes or configuration values needed between environments.
return in order to exit the (rule) function.
Minimize API requests
Calls to APIs, especially calls to third-party APIs, can slow down login response time and can cause rule timeout failures due to call latency, ultimately leading to authentication error situations. We recommend keeping API requests to a minimum wherever possible within a rule and avoiding excessive calls to paid services](#limit-calls-to-paid-services). We also recommend you avoid potential security exposure by limiting what is sent to any API—third party or otherwise.
global object can be used to cache information from API calls, which can subsequently be used across all rules that execute in the pipeline. Prefer to use this to store information instead of repeatedly calling an API. Additionally, the
global object can also be used to cache other information between executing rules.
Limit calls to paid services
If you have rules that call paid services, such as sending SMS messages via Twilio, make sure that you only use those services when necessary. This not only provides performance enhancement, but also helps to avoid extra charges. To help reduce calls to paid services:
- Disallow public sign-ups to reduce the number of users who can sign up and trigger calls to paid services
- Ensure that a rule only gets triggered for an authorized subset of users or other appropriate conditions. For example, you may want to add logic that checks if a user has a particular email domain, role/group, or subscription level before triggering the call to the paid service.
Limit calls to the Management API
Prefer to avoid calls to the Auth0 Management API. The Auth0 Management API is rate limited, which will still be a consideration even when using the
auth0 object (so be sure to use it sparingly). In addition, Management API functions take varying degrees of time to perform, so will incur varying degrees of latency; executing user search functionality, for example, should be kept to a minimum and performed only where absolutely necessary—even when executed via the
To see this in action, if you are using the Check if user email domain matches configured domain rule template, check out the latest version on Github or in the Auth0 Dashboard. Note: the recent changes will not alter functionality but will improve the performance of rules that had once relied on calls to the Management API.
Removing calls to the Management API (as well as the extra call required to get the appropriate Access Token) will make your rule code perform better and be more reliable.
Consider use of explicit timeouts when making API calls
When calling APIs or accessing external services, consider specifying explicit timeout(s). The specific timeout value you choose will typically vary based on your use case, but in general, choosing one that is as low as possible—while bearing in mind the performance characteristics of the external service—is advised.