É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.
Protection contre les attaques et API côté serveur
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.
- Sous Identifiants, sélectionnez une méthode d’authentification autre que
None.
- 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
-
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.
-
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.
Réponses de détection de violation de mot de passe
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."
}
Valider avec les journaux
type: sepft
...
ip: <ip from auth0-forwarded-for header>
client_ip: <ip of actual client/proxy>
...
