Brute-force protection is enabled by default for all connections. There are two different triggers for the brute-force protection shield, for two different attack scenarios:
10 consecutive failed login attempts for the same user and from the same IP address
100 failed login attempts from the same IP address in 24 hours or 50 sign up attempts per minute from the same IP address.
For example, if a user with user_id1 signs in from IP1 and fails to log in consecutively for 10 attempts, their login attempt from this IP1 will be blocked. Another user, user_id2, logging in from IP1 will not be blocked.
How it works
When brute-force protection is triggered, some or all of the following actions take can place:
Send an email to the affected user. (You can customize the email.)
Block the suspicious IP address for that user.
Notify dashboard administrator(s).
Block suspicious addresses for 15 minutes.
If blocks are triggered, they can be removed in the following ways:
An administrator can remove the block.
The user can click on the unblock link provided in the email sent when the block went into effect.
The user can change their password.
Restrictions and limitations
Brute-force protection depends on the IP address of the user. Because of this, the following use cases are not supported:
If you use the Resource Owner from the backend of the application. Using this call does not get the IP address of the user.
If you use Resource Owner Password Grant from the backend of the application. Using this call does not get the IP address of the user, however, you can configure your application and send the IP address of the user as part of the request to make brute-force protection work correctly.
If you authenticate a large number of users from the same IP address. For example, users that are behind a proxy are more likely to reach these limits and trigger the associated protection. It is possible to configure a whitelist for the proxy's IP and CIDR range and avoid erroneously triggering the protection.