Because the Resource Owner Password (ROP) Flow involves the application handling the user’s password, it must not be used by third-party clients.
Though we do not recommend it, highly-trusted applications can call server-side APIs using the Resource Owner Password Flow (sometimes called Password Grant or ROPG), which requests that users provide credentials (username and password), typically using an interactive form. If brute-force protection is enabled, when Auth0 validates the credentials, we may also check for attacks and perform appropriate actions if an attack is detected. Unfortunately, when using this flow with , some features may fail. Some common issues, however, can be avoided.

​
Attack protection and server-side APIs

Brute-force protection and rely on having the user’s IP address. When calling an API from your server, Auth0 treats the IP address of your server as the IP address of the user and provides it as input to the brute-force protection and suspicious IP throttling functionality. This could potentially trigger false positives, causing attack protection to block users or trigger warnings for legitimate requests. To avoid this, send the user’s IP address to Auth0 along with their credentials, and configure your application to trust the IP address.
Due to security considerations, you may only configure authenticated applications (such as those with authentication based on a client secret) this way. Authenticated applications must only be used from protected resources, which are typically server-side. Do not use them from native applications or Single-page applications (SPAs) because they are not capable of storing secrets.

​
Configure your Application to trust the IP address

Register either a regular web application or a machine-to-machine application. While configuring the application:
  1. Under Credentials, select an Authentication Method other than None.
  2. Under Settings > Advanced Settings, locate the OAuth tab, and enable Trust Token Endpoint IP Header, which will set the auth0-forwarded-for header as a trusted source of the user’s IP address for brute-force protection. This setting will not be available for non-authenticated applications.

​
Send the user’s IP address from your server

  1. When you request tokens using the Resource Owner Password Flow, include an auth0-forwarded-for header that contains the value of the user’s IP address. Be sure that the IP address you provide really belongs to your user.
    Trusting headers like the auth0-forwarded-for (or, in general, data from applications) as sources for the user’s IP address can be risky. Because this header is easy to spoof and makes it possible to bypass attack protection validation, only do this if you know you can trust that header.
  2. Specify AllowLists of IPs to be ignored when triggering brute-force protection and suspicious IP throttling.

​
Allow listing with brute-force protection and suspicious IP throttling

If your authenticated application is configured to send the auth0-forwarded-for header:
  • Only the IP address contained in the auth0-forwarded-for header is checked against the brute-force protection and suspicious IP throttling AllowLists.
  • The proxy IP address is ignored by brute-force protection and suspicious IP throttling, so doesn’t need to be added to the AllowLists.
  • If specific clients that use the proxy should not be subject to brute-force protection or suspicious IP throttling, add them to the AllowLists.
The auth0-forwarded-for header will only be accepted for authenticated calls with the Client Secret. If your application is not authenticated or is not configured to send the auth0-forwarded-for header:
  • The originating IP address of each request is checked against the brute-force protection and suspicious IP throttling AllowLists.
  • If you AllowList the IP proxy, all traffic passing through the proxy will be exempt from brute-force protection and suspicious IP throttling. This is probably not what you want.

​
Example

var request = require("request");

app.post('/api/auth', function(req, res, next) {
  var options = {
    method: 'POST',
    url: 'https://{yourDomain}/oauth/token',
    headers: {
      'content-type': 'application/x-www-form-urlencoded',
      'auth0-forwarded-for': req.ip // End user ip
    },
    form: {
      grant_type: 'password',
      username: 'USERNAME',
      password: 'PASSWORD',
      audience: 'YOUR_API_IDENTIFIER',
      scope: 'SCOPE',
      client_id: '{yourClientId}',
      client_secret: 'YOUR_CLIENT_SECRET' // Client is authenticated
    }
  };

  request(options, function (error, response, body) {
    if (error) return next(error);

    // ...
  });
});

​
Handle Breached Password Detection responses

If you’ve enabled Breached Password Detection for your tenant, you need to configure your application to handle responses from the Auth0 Authentication API accordingly. For example, if you send a password using the ROP flow, and Auth0 detects that it’s been compromised, the Authentication API returns a response with the HTTP 401 Unauthorized status code and the following body: 
{
    "error": "password_leaked",
    "error_description": "This login attempt has been blocked because the password you're using was previously disclosed through a data breach (not in this application). Please check your email for more information."
}
Your application should handle this error, render a message to the user, and trigger an interactive password reset flow.

​
Validate with logs

If your settings are working correctly, you will see the following in the logs: 
type:  sepft
...
ip:  <ip from auth0-forwarded-for header>
client_ip:  <ip of actual client/proxy>
...

​
Learn more