Passer au contenu principal
Étant donné que le flux ROP (Resource Owner Password) implique que l’application gère le mot de passe de l’utilisateur, il ne doit pas être utilisé par des clients tiers.
Bien que nous ne le recommandons pas, les applications hautement fiables peuvent utiliser le Flux de mot de passe du propriétaire de ressource, (parfois appelé consentement de mot de passe au propriétaire de la ressource ou ROPG), qui demande aux utilisateurs de fournir des informations d’identification (nom d’utilisateur et mot de passe), généralement à l’aide d’un formulaire interactif. Si la protection contre la force brute est activée, lorsque Auth0 valide les informations d’identification, nous pouvons également vérifier les attaques et effectuer les actions appropriées si une attaque est détectée. Malheureusement, lorsque vous utilisez ce flux avec une protection contre les attaques de force brute, certaines fonctionnalités de protection contre les attaques peuvent échouer. Certains problèmes courants peuvent toutefois être évités.

​
Protection contre les attaques et API côté serveur

La protection contre la force brute et la limitation des adresses IP suspectes reposent sur la connaissance de l’adresse IP de l’utilisateur. Lors de l’appel d’une API depuis votre serveur, Auth0 traite l’adresse IP de votre serveur comme adresse IP de l’utilisateur et la fournit en entrée pour la protection contre la force brute et la fonctionnalité de filtrage des IP suspectes. Cela pourrait potentiellement déclencher de faux positifs, obligeant la protection contre les attaques à bloquer les utilisateurs ou à déclencher des avertissements pour des demandes légitimes. Pour éviter cela, envoyez l’adresse IP de l’utilisateur à Auth0 avec ses informations d’identification et configurez votre application pour qu’elle approuve l’adresse IP.
Pour des raisons de sécurité, vous ne pouvez configurer de cette manière que des applications authentifiées (comme celles utilisant un secret client pour l’authentification). Les applications authentifiées ne doivent être utilisées qu’à partir de ressources protégées, qui sont généralement côté serveur. Ne les utilisez pas dans des applications natives ou des applications monopages (SPA), car elles ne peuvent pas stocker de secrets.

​
Configurer votre application pour faire confiance à l’adresse IP

Enregistrez soit une application Web standard, soit une application de communication entre machines. Lors de la configuration de l’application :
  1. Sous Identifiants, sélectionnez une méthode d’authentification autre que None.
  2. Sous Advanced Settings (Paramètres avancés), recherchez l’onglet Oauth et activez Faire confiance à l’IP indiqué dans l’entête du point de terminaison du jeton, qui définira l’en-tête auth0-forwarded-for comme source fiable de l’adresse IP de l’utilisateur pour la protection contre la force brute. Ce paramètre ne sera pas disponible pour les applications non authentifiées.

​
Envoyer l’adresse IP de l’utilisateur depuis votre serveur

  1. Lorsque vous demandez des jetons à l’aide du flux de mot de passe du propriétaire de ressource, incluez un en-tête auth0-forwarded-for qui contient la valeur de l’adresse IP de l’utilisateur. Assurez-vous que l’adresse IP que vous fournissez appartient réellement à votre utilisateur.
    Faire confiance à des en-têtes comme auth0-forwarded-for (ou, en général, à des données provenant d’applications) en tant que sources de l’adresse IP de l’utilisateur peut s’avérer risqué. Comme cette en-tête est facile à usurper et permet de contourner la validation de la protection contre les attaques, n’effectuez cette opération que si vous avez la certitude de pouvoir faire confiance à cette en-tête.
  2. Spécifiez les listes blanches d’adresses IP à ignorer lors du déclenchement de la protection contre la force brute et de la limitation d’adresses IP suspectes.

Autoriser l’énumération avec une protection contre les attaques exhaustives et la limitation pour les adresses IP suspicieuses

Si votre application authentifiée est configurée pour envoyer l’en-tête auth0-forwarded-for :
  • Seule l’adresse IP contenue dans l’en-tête auth0-forwarded-for est vérifiée par la protection contre les attaques exhaustives et les listes blanches (AllowLists) de limitation pour les adresses IP suspectes.
  • L’adresse IP du proxy est ignorée par la protection contre les attaques exhaustives et la limitation pour les adresses IP suspicieuses, et il n’est donc pas nécessaire de l’ajouter aux listes blanches (AllowLists)
  • Pour les clients spécifiques qui utilisent le proxy et qui ne devraient pas être sujets à la protection contre les attaques exhaustives et la limitation pour les adresses IP suspicieuses, ajoutez-les aux AllowLists.
L’en-tête auth0-forwarded-for sera uniquement acceptée pour les appels authentifiés avec le secret client. Si votre application n’est pas authentifiée ou qu’elle n’est pas configurée pour envoyer l’entête auth0-forwarded-for :
  • l’adresse IP d’origine de chaque requête est vérifiée par la protection contre les attaques exhaustives et les listes blanches (AllowLists) de limitation pour les adresses IP suspicieuses.
  • Si vous ajoutez l’IP d’un proxy à l’AllowList, tout le traffic qui passe par le proxy sera exempt de la protection contre les attaques exhaustives et la limitation pour les adresses IP suspicieuses. Ce n’est probablement pas ce que vous voulez.

​
Exemple

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);

    // ...
  });
});

​
Réponses de détection de violation de mot de passe

Si vous avez activé Détection de mot de passe violé pour votre locataire, vous devez configurer votre application pour gérer les réponses de l’Authentication API Auth0 en conséquence. Par exemple, si vous envoyez un mot de passe à l’aide du flux ROP et qu’Auth0 détecte qu’il a été compromis, l’Authentication API renvoie une réponse avec le code d’état HTTP 401 Unauthorized et le texte suivant : 
{
    "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."
}
Votre application doit gérer cette erreur, afficher un message à l’utilisateur et déclencher un flux de réinitialisation de mot de passe interactif.

​
Valider avec les journaux

Si vos paramètres fonctionnent correctement, vous verrez ce qui suit dans les journaux : 
type:  sepft
...
ip:  <ip from auth0-forwarded-for header>
client_ip:  <ip of actual client/proxy>
...

​
En savoir plus

⌘I