Avoid Common Issues with Resource Owner Password Flow and Attack Protection

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, 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 brute-force protection, some attack protection features may fail. Some common issues, however, can be avoided.

Attack protection and server-side APIs

Brute-force protection and suspicious IP throttling 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:

  • Under Settings, select a Token Endpoint Authentication Method other than None.

  • Under 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. Both the auth0-forwarded-for IP address and the IP address of the proxy server will be included in IP address AllowLists. Avoid erroneously triggering protection by configuring an AllowList for the proxy's IP and CIDR range.

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.

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

to configure this snippet with your account

var request = require("request");

app.post('/api/auth', function(req, res, next) {
  var options = {
    method: 'POST',
    url: 'https://YOUR_DOMAIN/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: 'YOUR_CLIENT_ID',
      client_secret: 'YOUR_CLIENT_SECRET' // Client is authenticated
    }
  };

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

    // ...
  });
});

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