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 offering is an available add-on to enterprise subscriptions that enhances an existing Public Cloud deployment. This offering allows a  dynamic increase of the Authentication API request limit to a multiplier of the default enterprise request limit of 100 RPS for up to 48 hours monthly.

Currently, the Public Performance 2X (multiplier) is available, allowing 200 RPS for the Authentication API for up to 48 hours monthly. The 48 hours are counted and deducted from the monthly allowed quota in 15-minute intervals, which enables usage of the API at the multiplier level for 192 15-minute intervals each month.

When the volume of requests for the Authentication API exceeds the default of 100 RPS, a 15-minute interval is deducted from the monthly allowance, and traffic is allowed at the rate associated with the multiplier. Traffic can stay within the multiplier range for the complete contiguous 15 minutes from that point without triggering additional deductions.

Monitoring of the interval deduction events is possible through tenant logs. Each deduction generates an associated `appi` tenant log event type containing information about the already consumed and remaining allowance.

For more information, see the Authentication API section in Rate Limits - 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