Rate Limits & Lockout

Two separate mechanisms protect the server:

• Rate limiting caps how many requests one client IP may send, across every protocol and API endpoint.
• Brute-force protection caps password guesses per IP and per identifier, and soft-locks an account after repeated failures.

Both identify the caller by client IP, resolved through security.trusted_proxies. Set that to your ingress or load balancer, or every request appears to come from the proxy and one noisy client throttles everybody.

#Rate limiting

The two backends behave differently:

The production Helm profile uses redis.

One budget per IP. Every rate-limited endpoint draws from the same per-IP budget: /authorize, /token, the sign-in API, the admin API and the hosted UI's pages all count together. Discovery and the JWKS are not rate-limited, and neither are the RFC 7592 management calls on /register/{client_id}.

When the limit is hit, the server answers 429 with a problem document and these headers. OAuth endpoints answer this way too, not with an OAuth error object:

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
X-RateLimit-Limit: 3000
X-RateLimit-Remaining: 0
Retry-After: 12
 
{"type":"urn:problem-type:rate_limited","title":"Too Many Requests","status":429,
 "code":"rate_limited","detail":"rate limit exceeded","instance":"/token","request_id":"…"}

Retry-After is in whole seconds, at least 1.

When the backend fails. The protocol and API endpoints fail closed: if the limiter cannot answer, they return 429. With the redis backend, a Redis outage therefore refuses every one of those requests until Redis is back. The hosted UI's pages fail open, so the sign-in screen still loads.

#Brute-force protection

The per-IP and per-identifier throttles are held in the cache, so with Redis they are shared by every replica. The account lock is stored on the user record in the database.

#Account lockout

After max_failed_attempts failures, the account is locked for lockout_duration. With backoff on, each failure after that doubles the next lock, up to lockout_max. While the account is locked, every attempt is refused, including one with the right password, and refused attempts neither count as failures nor extend the lock. So a third party cannot keep an account locked longer by guessing at it.

A successful sign-in clears the failure count. Setting the user's password through the admin API (PUT /v1/admin/orgs/{slug}/users/{id}/password) clears the count and the lock at once. That is the only way to unlock an account early; a dedicated unlock action is planned (#584).

#What the sign-in screen sees

By default a locked account looks the same as a throttled one, so the response does not confirm that the account exists. Answering identically for registered and unknown identifiers in every case is still open work (#293).

#Second factors

TOTP codes have their own lockout, independent of the account lock: after mfa.max_failures (5) wrong codes the factor is locked for mfa.lock_duration (15m). See Multi-Factor Authentication. The device flow's code entry allows five wrong user codes per signed-in user, after which entry is refused with too_many_attempts.

#Monitoring

• nauthera_auth_logins_total counts sign-in outcomes, including throttled and locked.
• nauthera_auth_account_lockouts_total counts accounts locked.
• auth.rate_limit.triggered audit events record tripped throttles. Recording the moment an account locks, once per lock, is tracked in #521.