Passer au contenu principal
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).
Comme nous prévoyons de supprimer les fonctions Règles et Hooks en 2026, vous devez créer de nouvelles Règles ou de nouveaux Hooks uniquement dans votre environnement de développement et uniquement pour tester la migration vers les Actions.Pour apprendre à migrer vos Règles vers des Actions, consultez Migrer des règles vers les actions. Pour apprendre à migrer vos Hooks vers des Actions, consultez la section Migrer des Hooks vers les actions.
Vous pouvez créer vos propres règles pour répondre à vos besoins particuliers en matière de fonctionnalités. Vous pouvez modifier un modèle de règle préexistant ou choisir de commencer à partir de zéro en utilisant l’un de nos exemples. Auth0 fournit un certain nombre de règles et de modèles de règles préexistants pour vous aider à atteindre votre ou vos objectif(s). Pour voir une liste, visitez notre Répertoire de règles sur GitHub.

Fonctionnement des règles

Les règles sont des fonctionnalités JavaScriptqui s’exécutent lorsqu’un utilisateur s’authentifie auprès de votre application. Elles sont exécutées une fois le processus d’authentification terminé, et vous pouvez les utiliser pour personnaliser et étendre les capacités d’Auth0. Pour des raisons de sécurité, le code de vos règles s’exécute dans un bac à sable, isolé du code des autres locataires Auth0. Les règles sont également exécutées pendant le flux d’actualisation des jetons. Pour en savoir plus, lisez Jetons d’actualisation Dans Auth0, le flux de transactions d’authentification fonctionne comme suit lorsque vous utilisez des règles :
Rules in the Authentication Flow diagram
  1. Une application lance une demande d’authentification auprès d’Auth0.
  2. Auth0 transmet la demande à un fournisseur d’identité au moyen d’une connexion configurée.
  3. L’utilisateur s’authentifie avec succès.
  4. Le jeton d’ID et/ou d’accès passe par le pipeline de règles, puis est envoyé à l’application.

Conditions préalables

Si vous prévoyez d’utiliser des variables globales dans votre règle, veillez à configurer d’abord les variables de vos règles. Pour en savoir plus, consultez Configuration des variables globales pour les règles.

Utiliser le Dashboard

  1. Accédez à Dashboard > Pipeline Auth > Règles et cliquez sur Créer.
    Dashboard - Auth Pipeline - Rules
  2. Sélectionnez un modèle de règle.
    Dashboard - Auth Pipeline - Rules - Template
  3. Nommez la règle, modifiez le script en fonction de vos besoins et cliquez sur Enregistrer les modifications.
    Dashboard - Auth Pipeline - Rules - Edit Rule

Utiliser Management API

Faites un appel POST au point de terminaison Créer une règle. Assurez-vous de remplacer les valeurs fictives MGMT_API_ACCESS_TOKEN, RULE_NAME, RULE_SCRIPT, RULE_ORDER, and RULE_ENABLED avec votre jeton d’accès au , le nom de la règle, le script de la règle, le numéro d’ordre de la règle et la valeur activée de la règle, respectivement.
curl --request POST \
  --url 'https://{yourDomain}/api/v2/rules' \
  --header 'authorization: Bearer MGMT_API_ACCESS_TOKEN' \
  --header 'cache-control: no-cache' \
  --header 'content-type: application/json' \
  --data '{ "name": "RULE_NAME", "script": "RULE_SCRIPT" }'
ValeurDescription
MGMT_API_ACCESS_TOKENJeton d’accès à Management API avec la permission create:rules.
RULE_NAMENom de la règle que vous souhaitez créer. Le nom de la règle ne peut contenir que des caractères alphanumériques, des espaces et des traits d’union; il ne peut pas commencer ou se terminer par des espaces ou des traits d’union.
RULE_SCRIPTScript contenant le code de la règle. Il doit correspondre à ce que vous entreriez si vous créiez une nouvelle règle à l’aide du Dashboard.
RULE_ORDER (facultatif)Entier qui représente l’ordre dans lequel la règle doit être exécutée par rapport à d’autres règles. Les règles dont le numéro est inférieur sont exécutées avant les règles dont le numéro est supérieur. Si aucun numéro d’ordre n’est fourni, la règle sera exécutée en dernier.
RULE_ENABLED (facultatif)Valeur booléenne qui représente si la règle est activée (true) ou désactivée (false).
Nous exposons les adresses IPv6 dans nos points de terminaison publics (par exemple, travel0.us.auth0.com). Si une demande provient d’une machine qui prend en charge IPv6, la propriété context.request.ip contiendra alors une adresse IPv6. Si vous manipulez manuellement des adresses IP, nous vous suggérons d’utiliser la bibliothèque ipaddr.js@1.9.0..

Gestion des limites anti-attaques

Pour les règles qui font appel aux API Auth0, vous devez toujours gérer la limite anti-attaques en vérifiant l’en-tête X-RateLimit-Remaining et en agissant de manière appropriée lorsque le nombre renvoyé se rapproche de 0. Vous devez également ajouter une logique pour gérer les cas où vous dépassez les limites anti-attaques fournies et recevez le code d’état HTTP 429 (trop de demandes); dans ce cas, si une nouvelle tentative est nécessaire, il est préférable de prévoir un délai pour éviter d’entrer dans une boucle infinie de tentatives. Pour en savoir plus sur les limites anti-attaques, consultez la Politique de limites anti-attaques pour les API Auth0.

Modules proposés

Les règles s’exécutent dans un bac à sable JavaScript configuré pour une version spécifique de Node.js. Le bac à sable prend en charge toutes les versions du langage JavaScript (et la syntaxe associée) pour la version spécifiée de Node.js, ainsi qu’un grand nombre de modules Node.js. Pour une liste des modules de bac à sable pris en charge, consultez Puis-je exiger : extensibilité Auth0.

En savoir plus

I