Skip to main content

​
Implémenter la connexion

Vous pouvez implémenter l’ en redirigeant vers le d’Auth0, en intégrant la connexion directement dans votre application ou en combinant les deux dans la même application. Universal Login constitue un bon choix par défaut lorsque vous souhaitez qu’Auth0 héberge l’interface de connexion et fournisse les mises à jour de façon transparente. La connexion intégrée convient lorsque vous souhaitez exercer un contrôle total sur l’interface et l’expérience utilisateur ou que vous créez une expérience native avec les API de clés d’accès ou Native Social Login. De nombreuses applications utilisent Universal Login pour la connexion principale et des flux intégrés pour l’enrôlement de clés d’accès dans l’application, la gestion des facteurs ou l’authentification renforcée. Pour comparer les compromis, consultez Hosted Login vs. Embedded Login. Pour savoir comment implémenter l’authentification sans mot de passe, consultez les articles suivants :

​
Utiliser les SMS et le courriel comme facteurs d’authentification

La mise en œuvre de l’authentification sans mot de passe d’Auth0 permet d’authentifier les utilisateurs à l’aide d’un seul facteur. Ce facteur peut être un code à usage unique envoyé par courriel ou par SMS, ou un Magic Link envoyé par courriel. Même si le courriel ou les SMS peuvent être plus sécuritaires qu’un mot de passe faible, les deux présentent des limites connues :
  • Les numéros de téléphone ne suffisent pas à l’authentification des utilisateurs. Le système d’acheminement téléphonique SS7 utilisé par les réseaux cellulaires présente des faiblesses connues, si bien qu’il n’est pas recommandé comme facteur d’authentification. Il existe de nombreux vecteurs d’attaque, allant de l’ingénierie sociale au remplacement de cartes SIM et à l’achat d’accès au réseau SS7.
  • La possession d’une adresse courriel ne suffit pas à l’authentification des utilisateurs (les alias, le transfert de courriels et les comptes partagés par plusieurs personnes en sont quelques exemples). Les fournisseurs de courriel n’appliquent pas tous les mêmes pratiques de sécurité, et certains n’exigent aucune vérification de l’identité de l’utilisateur. SMTP est un très ancien protocole, et de nombreux fournisseurs acheminent encore le trafic SMTP sans chiffrement, ce qui accroît le risque d’interception.
Pour ces raisons, nous recommandons que, si vous utilisez l’authentification sans mot de passe, vous mettiez aussi en œuvre la Multi-factor Authentication (MFA) au moyen d’un facteur différent lorsque l’utilisateur effectue une opération sensible sur le plan de la sécurité.

​
Se prémunir contre les attaques d’hameçonnage

Voici à quoi pourrait ressembler une attaque d’hameçonnage :
  1. L’utilisateur clique sur un lien dans un courriel ou sur un site Web malveillant.
  2. L’utilisateur arrive sur le faux site de l’attaquant, où il est invité à entrer son numéro de téléphone pour s’authentifier.
  3. L’utilisateur entre son numéro de téléphone, et l’attaquant saisit ce même numéro dans l’application légitime.
  4. L’application légitime envoie un SMS à l’utilisateur.
  5. L’utilisateur saisit le code à usage unique sur le site Web de l’attaquant.
  6. L’attaquant peut maintenant se connecter au site Web légitime.
Pour limiter les chances de réussite de cette attaque, l’utilisateur devrait s’attendre à ce que le SMS identifie clairement l’application. Vous devez configurer le modèle de SMS de façon à ce qu’il mentionne le nom du tenant et/ou le nom de l’application :

​
Prévenir les attaques par force brute

Auth0 offre les protections suivantes contre les attaques par force brute :
  • Seul le code à usage unique (ou le lien) émis le plus récemment sera accepté. Dès qu’un nouveau code ou lien est émis, tous les précédents sont invalidés. Une fois utilisé, le plus récent est lui aussi invalidé.
  • Un maximum de trois tentatives infructueuses de saisie d’un même code à usage unique est autorisé. Après cela, il faudra demander un nouveau code.
  • Le code à usage unique émis sera valide pendant trois minutes (par défaut) avant d’expirer.
  • Si un utilisateur sans mot de passe a été bloqué administrativement, Auth0 n’enverra aucun code OTP par SMS ou par courriel tant que l’utilisateur n’aura pas été débloqué. Ce comportement évite d’envoyer des requêtes inutiles à vos fournisseurs de SMS et de courriel.
La durée d’expiration du code à usage unique peut être modifiée dans Auth0 Dashboard > Authentication > Passwordless.

​
Prévenir les attaques d’énumération d’utilisateurs

L’énumération d’utilisateurs se produit lorsqu’un acteur malveillant utilise des techniques de force brute pour deviner ou confirmer l’existence d’utilisateurs valides dans un système. Lorsque Disable Sign Ups est activé, votre application peut devenir vulnérable aux attaques d’énumération d’utilisateurs. Auth0 recommande de ne pas activer ce paramètre afin d’assurer un niveau de sécurité maximal pour votre application et ses utilisateurs. Si vous activez malgré tout Disable Signs Ups, la Brute-force Protection peut réduire le risque associé à certaines de ces attaques, mais elle ne protège pas entièrement votre application. Les utilisateurs peuvent vouloir s’authentifier à l’aide de différents facteurs sans mot de passe au fil du temps. Par exemple, ils peuvent d’abord s’inscrire au moyen d’un SMS, puis commencer plus tard à s’authentifier par courriel. Vous pouvez le faire en leur permettant de lier leurs différents profils au moyen de la liaison de comptes.

​
Définir l’en-tête auth0-forwarded-for pour la limite de requêtes

Le point de terminaison /passwordless/start est assorti d’une limite de débit de 50 requêtes par heure et par adresse IP. Si vous appelez l’API côté serveur, l’adresse IP de votre backend peut facilement atteindre ces limites de débit. Pour savoir comment résoudre ce problème, consultez la section sur la limitation du débit dans les points de terminaison Passwordless de Utiliser les API Passwordless.