Rate Limit Policy

Auth0 limits the use of services to assure optimal performance and protection from bad actors, technical errors, or excessive legitimate traffic.  We recommend you review how Auth0 enforces limits to configure your application for the best user experience.

Auth0 enforces limitations to protect services from excessive requests and protect customers from service interruptions or degradation.

Auth0 observes, and in many cases, enforces an array of limits, including:

• Requests to environments (Private Cloud Only)

• Requests to tenants via API or API Endpoint

• Miscellaneous Limits

In Private Cloud, environment request limits are based on the Private Cloud Performance Tier.  To learn more, read Private Cloud for AWS or Private Cloud for Azure.

Currently,  Private Cloud environment rate limits represent the highest load under which the Auth0 product will meet SLAs.  However, at this time, Auth0 only enforces and notifies customers when rate limits have been exceeded on a specific tenant within the environment.  Under most Private Cloud use cases, where customers maintain a single Production Tenant, this is not a problem; however, use cases that provision more than one production tenant should consider the expected load across all tenants in the environment and implement additional monitoring as necessary.   

As an example, consider a Performance Plus environment, where the environment rate limit is 1500 rps.  It is possible to create two tenants in this environment, one serving clients at 1400 rps, and another serving clients at 900 rps.  Neither tenant will be rate limited, but a combined load across the environment of 2300 rps exceeds the environment rate limit by 800 rps.  As a result, user experience may be degraded, and the availability of the environment might fall below published SLAs.

For Private Cloud load testing considerations, refer to Private Cloud on AWS and Private Cloud on Azure.

Auth0 limits the number of requests that can be made on a tenant.  These limits are configured depending on the API, and further by specific endpoints on each API.

Auth0 limits the number of requests that can be made to a specific API, regardless of the API endpoint.  API limits may vary by: 

• API

• Tenant type

• Subscription level

For example, a free, non-production tenant could have different limits than a production tenant with a paid subscription.

Auth0 limits the number of requests made to API endpoints and, in some cases, the number of endpoint operations.  API endpoint limits also vary by:

• API

• Tenant type

• Subscription level

For example, a free, non-production tenant with a will have different limits than a production tenant with a paid subscription.

As requests to your tenant are made, Auth0 evaluates requests against the global limit for the API, and then evaluates requests against the rate limit for specific API endpoints.

For database connections, Auth0 limits certain types of repeat login attempts depending on the user account and IP address. To protect the overall health of the system, Auth0 employs user/password rate limits that mitigate load. Auth0's high degree of customization can put us at risk of service degradation. Causes can include:

• High-load stress tests

• Benchmark tests

• Inefficient code that causes users to log in multiple times

Requests are subject to limits as outlined in the individual policies for Auth0 APIs.

In addition, there is a same user login rate limit: If one IP address makes 20 login attempts in one minute to the same user account, the rate limit comes into effect. After that, Auth0 allows the user 10 attempts per minute. Any combination of successful and failed login attempts count toward this limit.

If you attempt to send more than 10 SMS messages to your device within one hour, you will receive an error message about a rate limit exception.

When you exceed your messaging limit, you need to wait at least one hour after the first message request before requesting another. You will receive an additional attempt after the passage of each additional hour.

Limits applied to Native Social login flow requests are identified based on the body of the requests with the following initial criteria:

The Public Performance SKU enhances the existing Public Cloud deployment by increasing the API Request Limit to a Peak Performance Request Limit of 2X.

Customers may exceed this API Request Limit, up to the Peak Performance Request Limit, for up to 48 hours monthly, in 15-minute increments for a total of 192 15-minute increments.

If the transaction limit bursts above the API-Request limit and exhausts the limit threshold of 100 RPS, then one 15-minute increment will be deducted, and the customer must use the remainder of that 15-minute increment to consume at the Peak Performance Request Limit within the 15-minute time frame before another increment is deducted.

For more information, see Enterprise.

Private Performance Burst offering (available AWS for 30x and 60x tiers currently) includes a burst (peak) performance capacity up to 30x (3,000 RPS) or 60x (6,000 RPS) for up to 80 hours per month. The base performance capacity, which is half of burst performance capacity, is available for the rest of the month. 

In other words, 30x Private Performance Burst has:

• Base capacity: 1,500 RPS for full month

• Burst/peak capacity: 3,000 RPS for up to 80 hours a month

If the Authentication transactions burst above the Base API-Request limit, then one hour is deducted from the monthly allowance. Traffic could stay at an elevated rate for the complete contiguous hour from that point. Additional deductions are done in the above fashion when the threshold is crossed again.

Once the 80 hours allowance is exhausted, the Authentication traffic will be rate limited to base capacity till the new monthly allowance takes effect.

To ensure system availability and fair use of system resources, Auth0 limits the number of concurrent in-flight requests across all extensibility products: Actions, Hooks, Rules, Custom Database Connections, Extensions, and Custom OAuth2 connections. Tenants that exceed their concurrent request limits should expect errors for new requests until in-flight requests are completed. The concurrency limits are defined below:

Concurrency can be calculated by multiplying expected RPS by the latency of each request. For example, a tenant that has two bound post-login Actions, which each take 250ms with a total login RPS of 400 have an expected concurrency of (2 * (400 requests / 1 second) * (.25 seconds / 1 request)) = 200.

To ensure that your tenant is not impacted by these concurrency limits, please ensure that potentially long-running extensibility logic, such as calls to external APIs, have reasonable timeouts.

Auth0 sets rate limits and burst limits for its APIs. While the rate limit is the maximum sustainable amount of traffic the system allows on a sustained basis, the burst limit is the maximum short-term traffic volume the system allows within one time interval. Auth0 rate limits and burst limits work together to provide better limiting functionality for dynamic traffic volume.

Auth0 rate limits use a token bucket algorithm containing the following configurations:

• Limit keys:  

  • Typically, a rate limit key is based on a two main factors:

    • API and endpoint

    • Tenant type 

  • In some cases, additional factors include:

    • Source IP

    • Target User ID 

• Limit values:

  • Bucket size: The maximum number of requests an API or endpoint receives in general, or receives from a specific user or IP address, before new requests are added.  

  • Refill rate:  The rate new requests are added to the bucket. 

From these two numbers, Auth0 calculates the burst limit and sustained rate limit:

• Burst limit:  Equal to bucket size. 

• Sustained rate limit:  Refill rate in requests per minute or second.

If the sustained rate limit is calculated in Requests per Second, new requests are added by milliseconds. If the sustained rate limit is calculated in Requests per Minute, new requests are added on a second basis.

• Entity Limit Policy
• Rate Limit Use Cases