Éviter les problèmes courants liés au flux Resource Owner Password et à la protection contre les attaques

Découvrez comment éviter les problèmes courants liés à l’utilisation du flux Resource Owner Password pour effectuer des requêtes aux API côté serveur lorsque la protection contre les attaques est activée.

Comme le flux Resource Owner Password (ROP) exige que l’application traite le mot de passe de l’utilisateur, il ne doit pas être utilisé par des clients tiers.

Bien que nous ne le recommandions pas, les applications hautement fiables peuvent appeler des API côté serveur à l’aide du flux Resource Owner Password (parfois appelé octroi de mot de passe du Resource Owner ou ROPG), qui demande aux utilisateurs de fournir des identifiants (nom d’utilisateur et mot de passe), généralement au moyen d’un formulaire interactif. Si la protection contre les attaques par force brute est activée, lorsque Auth0 valide les identifiants, nous pouvons aussi détecter des attaques et prendre les mesures appropriées si une attaque est détectée.

Malheureusement, lorsqu’on utilise ce flux avec la protection contre les attaques par force brute, certaines fonctionnalités de protection contre les attaques peuvent ne pas fonctionner. Certains problèmes courants peuvent toutefois être évités.

​

Protection contre les attaques et API côté serveur

La protection contre les attaques par force brute et Suspicious IP Throttling reposent sur l’adresse IP de l’utilisateur. Lorsque vous envoyez une requête à une API depuis votre serveur, Auth0 considère l’adresse IP de votre serveur comme étant celle de l’utilisateur et l’utilise comme donnée d’entrée pour la protection contre les attaques par force brute et Suspicious IP Throttling. Cela peut entraîner de faux positifs et amener la protection contre les attaques à bloquer des utilisateurs ou à générer des avertissements pour des requêtes légitimes.

Pour éviter cela, envoyez l’adresse IP de l’utilisateur à Auth0 avec ses identifiants, puis configurez votre application pour qu’elle se fie à cette adresse IP.

Pour des raisons de sécurité, seules les applications authentifiées (par exemple, celles dont l’authentification repose sur un secret client) peuvent être configurées de cette façon. Les applications authentifiées doivent être utilisées uniquement à partir de ressources protégées, qui sont généralement côté serveur. Ne les utilisez pas à partir d’applications natives ou d’applications monopages (SPA), car elles ne peuvent pas stocker de secrets.

​

Configurez votre application pour faire confiance à l’adresse IP

Enregistrez soit une application Web régulière, soit une application machine à machine. Pendant la configuration de l’application :

1. Sous Identifiants, sélectionnez une méthode d’authentification autre que None.
2. Sous Paramètres > Paramètres avancés, repérez l’onglet OAuth et activez Faire confiance à l’en-tête IP du point de terminaison de jeton, ce qui fera de l’en-tête auth0-forwarded-for une source fiable de l’adresse IP de l’utilisateur pour la protection contre les attaques par force brute. Ce paramètre ne sera pas disponible pour les applications sans authentification.

​

Envoyez l’adresse IP de l’utilisateur depuis votre serveur

1. Lorsque vous demandez des jetons au moyen du Resource Owner Password Flow, incluez un en-tête auth0-forwarded-for contenant la valeur de l’adresse IP de l’utilisateur. Assurez-vous que l’adresse IP que vous fournissez appartient bien à votre utilisateur.

   Se fier à des en-têtes comme auth0-forwarded-for (ou, plus généralement, à des données provenant d’applications) comme source de l’adresse IP de l’utilisateur peut être risqué. Comme cet en-tête est facile à usurper et qu’il permet de contourner la validation de la protection contre les attaques, ne faites cela que si vous êtes certain de pouvoir vous y fier.

2. Définissez des listes d’autorisation d’adresses IP à ignorer lors du déclenchement de la protection contre les attaques par force brute et de Suspicious IP Throttling.

Liste d'autorisation avec la protection contre les attaques par force brute et Suspicious IP Throttling

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 rapport aux listes d’autorisation de la protection contre les attaques par force brute et de Suspicious IP Throttling.
• L’adresse IP du proxy est ignorée par la protection contre les attaques par force brute et Suspicious IP Throttling; elle n’a donc pas besoin d’être ajoutée aux listes d’autorisation.
• Si certaines applications clientes qui utilisent le proxy ne doivent pas être assujetties à la protection contre les attaques par force brute ou à Suspicious IP Throttling, ajoutez-les aux listes d’autorisation.

L’en-tête auth0-forwarded-for ne sera accepté que pour les requêtes authentifiées avec le Client Secret. Si votre application n’est pas authentifiée ou n’est pas configurée pour envoyer l’en-tête auth0-forwarded-for :

• L’adresse IP d’origine de chaque requête est vérifiée par rapport aux listes d’autorisation de la protection contre les attaques par force brute et de Suspicious IP Throttling.
• Si vous ajoutez l’IP du proxy à une liste d’autorisation, tout le trafic acheminé par le proxy sera exempté de la protection contre les attaques par force brute et de Suspicious IP Throttling. Ce n’est probablement pas ce que vous voulez.

​

Exemple

​

Gérer les réponses de Breached Password Detection

Si vous avez activé Breached Password Detection pour votre tenant, vous devez configurer votre application pour gérer correctement les réponses de l’API d’authentification Auth0.

Par exemple, si vous envoyez un mot de passe au moyen du flux ROP et qu’Auth0 détecte qu’il a été compromis, l’API d’authentification renvoie une réponse avec le code d’état HTTP 401 Unauthorized et le corps 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 processus interactif de réinitialisation du mot de passe.

​

Valider à l’aide des journaux

Si vos paramètres sont configurés 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

• Resource Owner Password Flow
• Effectuer une requête vers votre API à l’aide du Resource Owner Password Flow
• protection contre les attaques