Passer au contenu principal
Comme le flux Resource Owner Password (ROP) exige que l’application gère le mot de passe de l’utilisateur, il ne doit pas être utilisé par des applications tierces.
Bien que nous ne le recommandions pas, les applications hautement fiables peuvent appeler des API côté serveur au moyen du flux Resource Owner Password (parfois appelé Password Grant 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 la 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 repérée. Malheureusement, lorsque vous utilisez ce flux avec la , certaines fonctionnalités de peuvent ne pas fonctionner. Toutefois, il est possible d’éviter certains problèmes courants.

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

La protection contre la force brute et la dépendent de l’adresse IP de l’utilisateur. Lorsque vous appelez 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 la force brute et la fonctionnalité de limitation du débit des IP suspectes. Cela peut entraîner des faux positifs et amener la protection contre les attaques à bloquer des utilisateurs ou à émettre 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é, vous ne pouvez configurer de cette façon que des applications authentifiées (par exemple, celles dont l’authentification repose sur un Secret client). Les applications authentifiées doivent être utilisées uniquement à partir de ressources protégées, 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 qu’elle fasse confiance à l’adresse IP

Enregistrez soit une application Web classique, soit une application de machine à machine. Lors de la configuration de l’application :
  1. Sous Credentials, sélectionnez une Authentication Method autre que None.
  2. Sous Settings > Advanced Settings, repérez l’onglet OAuth et activez Trust Token Endpoint IP Header. L’en-tête auth0-forwarded-for sera alors considéré comme une source fiable de l’adresse IP de l’utilisateur pour la protection contre les attaques par force brute. Ce paramètre n’est 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 Resource Owner Password, incluez un en-tête auth0-forwarded-for contenant l’adresse IP de l’utilisateur. Assurez-vous que l’adresse IP fournie appartient bien à votre utilisateur.
    Il peut être risqué de 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. Comme cet en-tête est facile à falsifier et peut permettre de contourner la validation de la protection contre les attaques, faites-le uniquement si vous êtes certain de pouvoir lui faire confiance.
  2. Définissez des listes d’autorisation d’adresses IP à ignorer pour la protection contre la force brute et la limitation des IP suspectes.

Liste d'autorisation avec protection contre la force brute et limitation des IP suspectes

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 pour la protection contre la force brute et la limitation des IP suspectes.
  • L’adresse IP du proxy est ignorée par la protection contre la force brute et la limitation des IP suspectes; elle n’a donc pas besoin d’être ajoutée aux listes d’autorisation.
  • Si certaines applications qui utilisent le proxy ne doivent pas être soumises à la protection contre la force brute ou à la limitation des IP suspectes, ajoutez-les aux listes d’autorisation.
L’en-tête auth0-forwarded-for ne sera accepté que pour les appels authentifiés à l’aide du Secret client. 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 pour la protection contre la force brute et la limitation des IP suspectes.
  • Si vous ajoutez l’IP du proxy à la liste d’autorisation, tout le trafic passant par le proxy sera exempté de la protection contre la force brute et de la limitation des IP suspectes. Ce n’est probablement pas ce que vous voulez.

​
Exemple

​
Gérer les réponses de la détection des mots de passe compromis

Si vous avez activé la détection des mots de passe compromis pour votre locataire, vous devez configurer votre application pour traiter correctement les réponses de l’Authentication API d’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’Authentication API 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 logs

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

​
En savoir plus