Feat/custom rate limit policies#1252
Open
nick-gagliardi wants to merge 11 commits into
Open
Conversation
b74ba98 to
2b72d5d
Compare
Contributor
Summary
|
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
- Add Auth0-RateLimit structured header documentation - Move throttling behavior under Monitor policy enforcement - Add 5 missing endpoints to counted requests table - Add Retry-After header and JSON error body details - Document /authorize 302 redirect behavior on rate limit - Clarify Default policy bucket isolation - Add once-per-minute log sampling detail - Add "Block an application entirely" subsection
d09d265 to
7bece03
Compare
avanscoy
reviewed
May 28, 2026
| description: Set per-application rate limit ceilings to protect your tenant from misconfigured or misbehaving applications. | ||
| --- | ||
|
|
||
| Custom rate limit policies let you set per-application request ceilings on your tenant's Authentication API. When an application calls Auth0 (requesting tokens, starting authorization flows, or refreshing credentials) each request counts toward that application's configured limit. If an application exceeds its ceiling due to a bug, retry loop, or unexpected behavior, Auth0 throttles it before it can consume your tenant's shared rate limit capacity. |
Contributor
There was a problem hiding this comment.
Suggested change
| Custom rate limit policies let you set per-application request ceilings on your tenant's Authentication API. When an application calls Auth0 (requesting tokens, starting authorization flows, or refreshing credentials) each request counts toward that application's configured limit. If an application exceeds its ceiling due to a bug, retry loop, or unexpected behavior, Auth0 throttles it before it can consume your tenant's shared rate limit capacity. | |
| Custom rate limit policies let you set per-application request ceilings on your tenant's calls to [Authentication API](https://auth0.com/docs/api/authentication). When an application calls Auth0 (requesting tokens, starting authorization flows, or refreshing credentials) each request counts toward that application's configured limit. If an application exceeds its ceiling due to a bug, retry loop, or unexpected behavior, Auth0 throttles it before it can consume your tenant's shared rate limit capacity. |
avanscoy
reviewed
May 28, 2026
avanscoy
reviewed
May 28, 2026
avanscoy
reviewed
May 28, 2026
|
|
||
| ### Pooled counters (Group policies) | ||
|
|
||
| Group policies use a single shared counter for all applications in the group. Every request from any group member draws from the same bucket. |
Contributor
There was a problem hiding this comment.
Suggested change
| Group policies use a single shared counter for all applications in the group. Every request from any group member draws from the same bucket. | |
| Group policies use a single, shared counter for all applications in the group. Every request from any group member draws from the same bucket. |
avanscoy
reviewed
May 28, 2026
|
|
||
| Group policies use a single shared counter for all applications in the group. Every request from any group member draws from the same bucket. | ||
|
|
||
| For example, if you create a Group policy called "Third-Party Clients" with a limit of 100 RPS, and the group contains five applications, the 100 RPS limit applies to their combined traffic. If one application sends 90 RPS and the others send 5 RPS each, the group has hit its limit (90 + 5 + 5 + 5 + 5 = 110 RPS) and subsequent requests from any application in the group are throttled. There is no guaranteed allocation per application within the group. |
Contributor
There was a problem hiding this comment.
Suggested change
| For example, if you create a Group policy called "Third-Party Clients" with a limit of 100 RPS, and the group contains five applications, the 100 RPS limit applies to their combined traffic. If one application sends 90 RPS and the others send 5 RPS each, the group has hit its limit (90 + 5 + 5 + 5 + 5 = 110 RPS) and subsequent requests from any application in the group are throttled. There is no guaranteed allocation per application within the group. | |
| For example, if you create a Group policy called "Third-Party Clients" with a limit of 100 RPS, and the group contains five applications, the 100 RPS limit applies to their combined traffic. If one application sends 90 RPS and the others send 5 RPS each, the group hits its limit (90 + 5 + 5 + 5 + 5 = 110 RPS). Auth0 throttles subsequent requests from any application in the group. There is no guaranteed allocation per application within the group. |
avanscoy
reviewed
May 28, 2026
| | Passkey challenge | `/passkey/challenge` | Back-channel call to initiate a passkey authentication challenge. | | ||
| | Passkey registration | `/passkey/register` | Back-channel call to register a new passkey. | | ||
|
|
||
| ## Requests excluded from custom rate limits |
Contributor
There was a problem hiding this comment.
Suggested change
| ## Requests excluded from custom rate limits | |
| ## Custom rate limit exclusions |
avanscoy
reviewed
May 28, 2026
|
|
||
| <Callout icon="file-lines" color="#0EA5E9" iconType="regular"> | ||
|
|
||
| Because browser-initiated requests are excluded, custom rate limit policies reduce but do not eliminate the risk of attacks that exhaust tenant-wide rate limits by triggering complete authentication flows. For protection against those attack patterns, see [Attack Protection](/docs/secure/attack-protection). |
Contributor
There was a problem hiding this comment.
Suggested change
| Because browser-initiated requests are excluded, custom rate limit policies reduce but do not eliminate the risk of attacks that exhaust tenant-wide rate limits by triggering complete authentication flows. For protection against those attack patterns, see [Attack Protection](/docs/secure/attack-protection). | |
| Because browser-initiated requests are excluded, custom rate limit policies reduce but do not eliminate the risk of attacks that exhaust tenant-wide rate limits by triggering complete authentication flows. For protection against those attack patterns, read [Attack Protection](/docs/secure/attack-protection). |
…ate-limit-policy/custom-rate-limit-policies.mdx Co-authored-by: Amanda VS <amanda.vanscoy@auth0.com>
…ate-limit-policy/custom-rate-limit-policies.mdx Co-authored-by: Amanda VS <amanda.vanscoy@auth0.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds a new documentation page explaining custom rate limit policies, which let customers set per-application request ceilings on the Authentication API to protect tenants from misconfigured or misbehaving applications.
What's covered
References
Testing
Checklist
CONTRIBUTING.md.