Rules execute as part of a pipeline that generates artifacts for authenticity, as described in Custom Database 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.

Implementing performance best practices in Auth0 ensures optimal execution of rules and authentication pipelines. These practices include avoiding unnecessary execution, minimizing API requests, and reducing calls to Auth0 services.

• Auth0
• Performance
• Best Practices
• Rules

Avoid Unnecessary Execution by Using Conditional Logic

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. Using clientMetadata makes adding new clients and reading rule code easier by reducing the code changes or configuration values needed between environments. Set client metadata for an application manually via the Auth0 Dashboard by navigating to Application Settings > Advanced Settings > Application Metadata or programmatically via the Auth0 Management API’s Update a client endpoint.

How does early exit optimize performance?

Write rules that complete as soon as possible. If a rule has multiple checks to decide if it should run, use the first check to eliminate the majority of cases, followed by the second check to eliminate the next largest set of cases. At the end of each check, execute the callback function combined with a JavaScript return to exit the rule function.

Minimize API Requests to Prevent Latency and Timeout Failures

Calls to APIs, especially calls to third-party APIs, slow down login response time and cause rule timeout failures due to call latency. This ultimately leads to authentication error situations. Keep API requests to a minimum wherever possible within a rule and avoid excessive calls to paid services. Avoid potential security exposure by limiting what is sent to any API. Use the global object to cache information from API calls, which can subsequently be used across all rules that execute in the pipeline. Use this to store information instead of repeatedly calling an API. Additionally, use the global object to cache other information between executing rules.

How does conditional logic limit calls to paid services?

When rules call paid services, such as sending Short Message Service (SMS) messages via Twilio, only use those services when necessary to enhance performance and avoid extra charges. Reduce calls to paid services by disallowing public sign-ups and ensuring rules only trigger for authorized users.

• Disallow public sign-ups to reduce the number of users who sign up and trigger calls to paid services.
• Ensure that a rule only triggers for an authorized subset of users or other appropriate conditions. 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

Avoid calls to the Auth0 Management API. The Auth0 Management API enforces rate limits, which remain a consideration even when using the auth0 object. Review the Management API Endpoint Rate Limits documentation for more information. Management API functions take varying degrees of time to perform and incur varying degrees of latency. Keep calls to the Management API’s List or Search users endpoint to a minimum and perform them only where absolutely necessary.

Why does avoiding calls to the Management API for connection-related details improve reliability?

Auth0 provides expanded connection-related properties available to the rules context object. Obtain connection information from the context object instead of calling the Auth0 Management API. To learn more, read Context Object Properties in Rules. For an example using the Check if user email domain matches configured domain rule template, check out the latest version on Github or navigate to Auth Pipeline > Rules in the Auth0 Dashboard and select Create.

NOTE: The recent changes do not alter functionality but improve the performance of rules that previously relied on calls to the Management API.

Removing calls to the Management API and the additional call required to obtain the appropriate Access Token improves the rule code's performance and reliability.

Use Explicit Timeouts When Making API Calls

When calling APIs or accessing external services, specify explicit timeouts. The specific timeout value varies by use case, but choosing the lowest possible value remains advised. Whether choosing explicit timeouts or implicit timeout processing, always cater to error or exception conditions that occur as a result of any timeout period expiration. Review the Auth0 Error Handling Best Practices documentation for more information.

How do caching and bulk call reduction decrease calls to Auth0?

When an environment exceeds rate limits, reduce the number of calls made to Auth0. Reduce calls to Auth0 by caching responses, requesting an ID token, and reducing bulk calls.

• Cache /.well-known/* responses. This information does not change frequently, and caching it reduces the number of times Auth0 receives calls.
• Request an id_token instead of calling /userinfo to get information about the user.
• Reduce bulk calls, such as bulk delete or bulk unlock.

Related References

• Auth0 Error Handling Best Practices
• Auth0 Debugging Best Practices