Skip to main content
La date de fin de vie (EOL) des Règles et des Appels sera le 18 novembre 2026. Ils ne sont plus disponibles pour les nouveaux locataires créés à partir du 16 octobre 2023. Les locataires actuels ayant des hooks actifs conserveront l’accès aux produit Hooks jusqu’à la fin de leur durée de vie.Nous vous conseillons vivement d’utiliser les Actions pour étendre Auth0. Avec les Actions, vous avez accès à des informations de type enrichies, à une documentation intégrée et à des packages npm publics, et vous pouvez connecter des intégrations externes qui optimisent votre expérience d’extensibilité globale. Pour en savoir plus sur ce que les Actions proposent, consultez Comprendre comment fonctionnent Auth0 Actions.Pour vous aider dans votre migration, nous proposons des guides qui vous aideront à migrer des Règles vers les Actions et à migrer des Hooks vers les Actions. Nous avons également une page dédiée à la Migration vers les Actions qui met en évidence les comparaisons de fonctionnalités, une démo des Actions et d’autres ressources pour vous aider dans votre parcours de migration.Pour en savoir plus sur l’obsolescence des Règles et des Appels, consultez notre article de blog : Preparing for Rules and Hooks End of Life (Préparation à la fin de vie des règles et des crochets).

​
Toujours utiliser HTTPS

Dans le cadre de l’implémentation de vos règles, utilisez toujours HTTPS, et non HTTP, en effectuant des appels vers des services externes ou lors de l’exécution d’une redirection.

​
Stocker les valeurs sensibles en matière de sécurité dans les paramètres de la règle

Les informations sensibles en matière de sécurité, telles que les informations concernant l’identification ou les clés API, doivent être stockées dans les paramètres de votre règle où elles seront masquées, chiffrées et disponibles via l’objet configuration. Ne stockez pas ces valeurs sous forme de littéraux dans votre code de règles. Par exemple, n’écrivez pas de code comme celui-ci : const myApiKey = ’abc123’; Optez plutôt pour stocker les informations (confidentielles) afin qu’elles soient accessibles par le biais de l’objet configuration : const myApiKey = configuration.myApiKey;

​
N’envoyez pas la totalité de l’objet context à des services externes

Pour les règles concernant l’envoie d’informations à un service externe, assurez-vous de ne pas envoyer la totalité de l’objet contexte, car cet objet peut contenir des jetons ou d’autres données confidentielles. Pour les règles concernant l’envoie d’informations à des services externes, vous ne devez envoyer qu’un sous-ensemble des attributs les moins confidentiels de l’objet context quand cela est nécessaire. De la même manière, évitez de transmettre tout aspect de l’objet auth0 à l’extérieur d’une règle.

​
Vérifier si un courriel est vérifié

Vous pouvez vérifier si l’adresse courriel d’un utilisateur est vérifiée dans une règle : 
function (user, context, callback) {
      // Access should only be granted to verified users.
      if (!user.email || !user.email_verified) {
    return callback(new UnauthorizedError('Access denied.'));
      }
    	  .
    	  .
    }
Toutefois, si vous voulez exécuter un code différent selon l’entreprise à laquelle appartient l’utilisateur, ne vous fiez au domaine de messagerie, mais plutôt aux données qui peuvent relier l’utilisateur au fournisseur d’identité auprès duquel il s’est authentifié (la connexion ou les champs propres au fournisseurs d’identités tels que letenant id d’Azure).

​
Vérifier l’exactitude de la correspondance des chaînes

Pour les règles qui déterminent le contrôle d’accès en fonction d’une chaîne particulière, telle qu’un domaine de messagerie, recherchez une correspondance exacte de la chaîne plutôt que de rechercher une correspondance de sous-chaîne. Si vous recherchez uniquement une sous-chaîne, votre règle risque de ne pas fonctionner comme prévu. Par exemple, dans : if( _.findIndex(connection.options.domain_aliases, function(d){ return user.email.indexOf(d) >= 0; le code (ci-dessus) retournerait true pour des courriels comme :
  • user.domain.com@not-domain.com
  • “user@domain.com”@not-domain.com (guillemets inclus)
ce qui n’est peut-être pas souhaité. Optez plutôt pour des correspondances exactes en utilisant un code tel que : const emailSplit = user.email.split(’@’); const userEmailDomain = emailSplit[emailSplit.length - 1].toLowerCase(); Pour en apprendre davantage, consultez Vérifier si le domaine de courriel de l’utilisateur correspond au modèle de règle de domaine configuré sur GitHub, ou naviguez vers Auth0 Dashboard > Pipeline d’Auth > Régles, et sélectionnez Créer.

​
Contournement contextuel pour l’authentification multifacteur (MFA)

L’authentification multifacteur () fournit une couche de sécurité supplémentaire pour protéger contre les accès non autorisés. Du point de vue de l’expérience utilisateur, cela nécessite généralement une interaction utilisateur de plus pour fournir un deuxième facteur d’authentification, c’est-à-dire présenter des identifiants supplémentaires ou autoriser une certaine forme de demande d’accès. Il existe toutefois des cas dans lesquels il peut être souhaitable de contourner la MFA pour un utilisateur désigné comme nécessitant une authentification multifacteur (MFA). Par exemple, il peut être souhaitable de contourner la MFA si un utilisateur a déjà présenté des facteurs primaires et secondaires à titre d’authentification dans le contexte actuel du navigateur. Cette vérification contextuelle peut contribuer à améliorer l’expérience utilisateur. Toutefois, si cela n’est pas bien fait, de graves failles de sécurité peuvent surgir, ce qui pourraient ultérieurement entraîner des violations en terme de sécurité en raison du non-respect de la MFA. Nous vous recommandons donc de respecter les conseils suivants lorsque vous décidez d’utiliser ou non le contournement contextuel de la MFA. En tant que meilleure pratique, l’utilisation de allowRememberBrowser ou de context.authentication doit être la seule option prise en compte pour le contournement contextuel lors de l’utilisation de la MFA prête à l’emploi. Régler allowRememberBrowser sur true permet aux utilisateurs de cocher une case afin qu’ils ne soient invités à effectuer la MFA que périodiquement, tandis que context.authentication peut être utilisé en toute sécurité et avec précision pour déterminer quand la MFA a été effectuée pour la dernière fois dans le contexte actuel du navigateur; vous pouvez voir un exemple d’utilisation de context.authentication dans la règle fournie prête à l’emploi, Exiger MFA une fois par session.
  • N’effectuez pas de contournement MFA basé sur une logique conditionnelle liée à l’authentification silencieuse (p. ex., context.request.query.prompt === ’none’)
  • N’effectuez pas de contournement MFA basé sur une logique conditionnelle utilisant une certaine forme d’empreinte digitale de l’appareil (p. ex., où user.app_metadata.lastLoginDeviceFingerPrint === deviceFingerPrint)
  • N’effectuez pas de contournement MFA basé sur une logique conditionnelle liée à l’emplacement géographique (p. ex., où user.app_metadata.last_location === context.request.geoip.country_code)

​
Vérification du contexte lors de l’utilisation de fournisseurs MFA personnalisés

Tout comme nous l’avons fait auparavant, nous vous recommandons de suivre les conseils fournis dans les éléments répertoriés ci-dessus pour toutes les règles qui redirigent les utilisateurs vers des fournisseurs de authentification multifacteur (MFA) personnalisés. Par exemple, pour les fournisseurs personnalisés, il n’existe aucun moyen sûr de contourner efficacement la MFA lors d’une authentification silencieuse, car la redirection (requise pour la MFA personnalisée) échouera toujours dans les situations d’authentification silencieuse.

​
En savoir plus

⌘I