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.
Introduction to Rate Limits
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
Environment request limits (Private Cloud Only)
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.
Tenant request limits
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.
API rate limits
Auth0 limits the number of requests that can be made to a specific API, regardless of the API endpoint. API limits may vary by:
For example, a free, non-production tenant could have different limits than a production tenant with a paid subscription.
Endpoint rate limits
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:
For example, a free, non-production tenant with a will have different limits than a production tenant with a paid subscription.
Tenant request limits order
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.
Database login limits
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
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.
Limits that protect users
SMS message limits for multi-factor authentication (end-users only)
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.
Native social login limits
Limits applied to Native Social login flow requests are identified based on the body of the requests with the following initial criteria:
Public Performance SKU is an add-on for Public Cloud Enterprise deployments that allows for a Sustained Request Rate with a Peak Performance Rate. The Customer is allotted 48 hours per month for the Peak Performance Rate, calculated in 15 minute increments, rounded up to the nearest 15th minute increment, whenever the requested transaction rate exceeds the sustained rate for at least two (2) consecutive seconds. For more information, see Enterprise.
Rate limit algorithm
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:
Typically, a rate limit key is based on a two main factors:
API and endpoint
In some cases, additional factors include:
Target User ID
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.