When an application uses the Resource Owner Password Grant (ROPG) to authenticate the same user more than four times in one second, it will receive a 429 response, and System Logs will contain a log with the `user_rate_limited` event. This is not configurable and will require reevaluating the implementation.

• OAuth 2.0 
• Resource Owner Password Grant (ROPG)

This error is caused by a specific per-user rate limit on the /oauth2/v1/token endpoint for the Resource Owner Password Grant. An application will trigger this error if it makes more than four authentication requests per second for the same user. This security control is in place to protect individual user accounts from brute force attacks and is specific to this OAuth 2.0 grant. This is a per-user rate limit, and is enforced without regard to the authorization server or client user.

The solution involves reviewing the application's authentication design and migrating to a more secure and robust grant type.

1. Review Application Logic and Token Caching

Before making other changes, investigate why the application is making so many token requests for a single user. Access tokens are designed to be long-lived. The application should:

• • Request a token once upon successful login.
  • Reuse the access_token for API calls until it expires.
  • Use the refresh_token to get a new token pair when the access token expires, without requiring the user to re-enter their credentials. 

2. Migrate to a Recommended Grant Type (Best Practice) 

Okta recommends migrating away from ROPG entirely due to its inherent security risks (direct handling of passwords).

• • For applications with an interactive user
    • The most secure method is the Authorization Code Flow (for traditional web applications) or Authorization Code Flow with PKCE (for single-page and native applications). This flow redirects the user to the Okta sign-in page and never exposes user credentials to the application.
  • For machine-to-machine services
    • Use the Client Credentials grant, which is designed specifically for non-interactive clients. Note that this does not return an ID token, and therefore may not work for programmatic testing use-cases.

Related References

• Okta API Rate Limits
• Implement the Resource Owner Password Flow
• Implement the Authorization Code Flow with PKCE
• Implement the Client Credentials Flow