Auth0’s built-in rate limiting is surprisingly granular, but most people miss that it’s not a single, global setting — it’s applied per endpoint and per IP address.
Let’s see it in action. Imagine a user trying to log in repeatedly with a bad password. Auth0 tracks this, not just for the user account, but for the IP address they’re coming from.
Here’s a simplified view of what Auth0’s logs might show for a brute-force attempt:
{
"type": "failed-login",
"client_id": "your_client_id",
"user_id": "auth0|user_id_for_user",
"ip": "1.2.3.4",
"user_agent": "Mozilla/5.0...",
"date": "2023-10-27T10:00:00Z",
"error": {
"name": "invalid_user_password",
"message": "Invalid username or password."
}
}
And then, after several failures from the same IP:
{
"type": "throttled-request",
"client_id": "your_client_id",
"ip": "1.2.3.4",
"date": "2023-10-27T10:05:00Z",
"rule": "rate-limit-login",
"message": "Too many failed login attempts."
}
This throttled-request event is the key. Auth0 has detected too many failed attempts from 1.2.3.4 on the login endpoint and is now blocking further requests from that IP for a period.
The problem Auth0 solves is simple: preventing unauthorized access by limiting the rate at which users or attackers can try to authenticate. It stops automated attacks like brute-force, credential stuffing, and denial-of-service attempts that target the authentication flow.
Internally, Auth0 maintains counters for various events, tied to specific identifiers like IP addresses, user IDs, or client IDs. When a request comes in, Auth0 checks these counters against configured thresholds. If a threshold is exceeded, the request is blocked, and a throttled-request event is logged.
The primary levers you control are within the Auth0 Dashboard under Security > Rate Limiting. You’ll find settings for:
- Login: Controls the rate of failed login attempts.
- Password Reset: Limits how often users can request password resets.
- Sign Up: Prevents rapid creation of new accounts.
- API Use: Limits calls to your Auth0 APIs.
Each of these has a default configuration, typically allowing a certain number of requests within a specific time window (e.g., 100 failed logins per IP per hour).
One thing most people don’t realize is how closely the "Block for" duration interacts with the "Number of attempts" and "Time window." If your time window is 1 hour and you set the limit to 100 attempts, and a user hits that limit at 10:30 AM, they’ll be blocked until 11:30 AM. If you then decrease the time window to 15 minutes but keep the limit at 100, the same user who was blocked until 11:30 AM might suddenly be unblocked at 10:45 AM if they haven’t made any new attempts in that shorter window. The system re-evaluates the block based on the current configuration and the remaining time in the block period.
To protect against sophisticated attacks, consider implementing your own IP blocking logic in your application’s middleware or using Auth0 Actions to add custom throttling based on more complex criteria.
The next problem you’ll likely encounter is managing false positives from legitimate users who might get blocked due to shared IPs or unusual network configurations.