Repository navigation
How to lock a client login on multiple failed attempts? #54304
Replies: 2 comments 3 replies
|
Since the OIDC API is public, basically anyone would be able to trigger the brute force protection mechanism and lock your clients, leading to service disruptions. User brute force protections can have a similar result, but locking out a single user likely has an overall smaller impact over the system, when compared to blocking clients. Using a long, random client secret or using other client authentication mechanisms (JWT or X509) should be make brute forcing the client credentials unreasonable for most attackers. Brute-forcing a 20-30 characters long, random alphanumeric password will likely result in a DoS long before an attacker could reasonably guess the password - a 20 character long, uniform random password has around 62^20 possible combinations. If you want to do something to restrict access, I would probably try using something like fail2ban to track repeated 401/403 HTTP responses and block the offending IPs. |
|
There isn't one. Brute force detection in Keycloak is keyed on a user: the It's been requested: keycloak/keycloak#30077 (open since June 2024, What you can do today:
If you still want a lockout, the only route is a custom |
|
Only note I have is that the "knows the client ID" is a very low bar, as the client ID is visible in the redirect URL from the client to Keycloak, so it's public information for all intents and purposes. |
|
Thanks @darius-m and @AZapata27! we do have WAF rate limiting, I was asked the question thinking there might have been some additional solution that locked the client service account that's used by a client. But i understand the justification to not do this. I wasn't aware that having signed JWT for client login was possible so I'll look that up as well. |
|
Glad it helped. Signed JWT is in the client credentials section of the admin guide; with a key pair there's no secret left to guess. If this answered your question, would you mind marking it as the answer? It helps the next person who searches for the same thing. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
For local users we can turn on/enable brute force protections to prevent malicious actors from trying to 'guess' passwords. What's the equivalent of this for a client based login with client id and secret? Is there a way to do this?
All reactions