Passer au contenu principal
Les règles s’exécutent dans le cadre d’un pipeline où des artefacts d’authenticité sont générés, comme décrit dans Bonnes pratiques d’anatomie des bases de données personnalisées. Ainsi, une règle activée s’exécutera pour chaque opération de connexion (interactive ou autre), chaque authentification silencieuse et chaque fois qu’un jeton d’accès lié aux informations d’identification de l’utilisateur est généré pour un appel d’API. Cela signifie que même dans les déploiements à petite échelle, les performances peuvent être un problème, qui ne fera que s’aggraver au fur et à mesure que l’échelle du déploiement augmentera.

​
Éviter l’exécution inutile

Préférez mettre en œuvre une exécution basée sur une logique conditionnelle. Par exemple, pour exécuter une règle uniquement pour des applications spécifiques, il convient de vérifier un clientID spécifique ou des clientMetadata spécifiques, en particulier lors de la vérification d’une valeur clientMetadata unique, commune à plusieurs applications. L’utilisation de clientMetadata peut également faciliter l’ajout de nouveaux clients (ainsi que la lecture du code des règles), en particulier si vous avez défini un grand nombre d’applications, en réduisant les modifications de code ou les valeurs de configuration nécessaires entre les environnements. Les métadonnées client d’une application peuvent être définies manuellement via en allant dans Paramètre de l’application > Paramètres avancés > Métadonnées de l’application ou de manière programmatique via l’utilisation du point de terminaison Mettre à jour un point de terminaison client de l’API d’authentification Auth0.

​
Terminer l’exécution tôt

Pour des performances optimales, écrivez des règles qui se terminent le plus tôt possible. Par exemple, si une règle comporte trois vérifications pour décider si elle doit être exécutée, utilisez la première vérification pour éliminer la majorité des cas, suivie de la vérification pour éliminer l’ensemble suivant de cas, et ainsi de suite. À la fin de chaque vérification, n’oubliez pas d’exécuter la fonction de rappel, idéalement combinée avec un (JavaScript) return afin de quitter la fonction (règle). Pour en savoir plus, lisez Les meilleures pratiques en matière d’exécution des règles.

​
Réduire les requêtes API

Les requêtes aux API, en particulier les requêtes aux API tierces, peuvent ralentir le temps de réponse de la connexion et provoquer des échecs du délai d’attente de la règle en raison de la latence de l’appel, ce qui conduit finalement à des situations d’erreur d’authentification. Nous recommandons de réduire au minimum les requêtes aux API dans la mesure du possible au sein d’une règle et d’éviter les appels excessifs à des services payants. Nous vous recommandons également d’éviter toute exposition de sécurité potentielle en limitant ce qui est envoyé à une API, qu’elle soit tierce ou non. L’objet global peut être utilisé pour mettre en cache les informations provenant des requêtes à l’API, lesquelles peuvent ensuite être utilisées dans toutes les règles qui s’exécutent dans le pipeline. Il est préférable d’utiliser cet objet pour stocker des informations plutôt que d’appeler plusieurs fois une API. En outre, l’objet global peut également être utilisé pour mettre en cache d’autres informations entre les règles en cours d’exécution.

​
Limiter les requêtes aux services payants

Si vos règles font des requêtes à des services payants, tels que l’envoi de messages SMS via Twilio, veillez à n’utiliser ces services qu’en cas de nécessité. Cela permet non seulement d’améliorer les performances, mais aussi d’éviter les frais supplémentaires. Afin de réduire les requêtes aux services payants :
  • Interdire les inscriptions publiques pour réduire le nombre d’utilisateurs pouvant s’inscrire et déclencher des appels à des services payants.
  • Veillez à ce qu’une règle ne soit déclenchée que pour un sous-ensemble autorisé d’utilisateurs ou dans d’autres conditions appropriées. Par exemple, vous pouvez ajouter une logique qui vérifie si un utilisateur possède un domaine de messagerie, un rôle/groupe ou un niveau d’abonnement particulier avant de déclencher la requête au service payant.

​
Limiter les requêtes à Management API

Essayez d’éviter les appels à Auth0. Management API Auth0 est limitée en termes de taux, un facteur à prendre en compte même lorsque l’on utilise l’objet auth0 (veillez donc à l’utiliser avec parcimonie). Pour en savoir plus, consultez Limites anti-attaques des points de terminaison de Management API. En outre, l’exécution des fonctions de Management API prend plus ou moins de temps et entraîne donc une latence plus ou moins importante; l’appel au point de terminaison Lister ou chercher des points de terminaison d’utilisateurs de Management API, par exemple, doit être réduit au minimum et n’être effectué qu’en cas d’absolue nécessité, même lorsqu’il est exécuté via l’objet auth0. Nous avons étendu les propriétés liées à la connexion à l’objet context des règles, de sorte que vous pouvez obtenir des informations sur la connexion à partir de l’objet context au lieu d’avoir besoin d’appeler Management API Auth0. Pour en savoir plus, lisez Propriétés de l’objet contexte dans les règles. Pour voir cela en action, si vous utilisez le modèle de règle Check if user email domain matches configured domain (Vérifier si le domaine du courriel de l’utilisateur correspond au domaine configuré), vérifiez la dernière version sur Github ou naviguez vers Auth0 Dashboard > Auth Pipeline (Pipeline Auth) > Rules (Règles), et sélectionnez Create (Créer). Remarque : les changements récents ne modifieront pas les fonctionnalités, mais amélioreront les performances des règles qui dépendaient auparavant des appels à Management API. La suppression des appels à Management API (ainsi que l’appel supplémentaire requis pour obtenir le jeton d’accès approprié) améliorera les performances et la fiabilité du code de votre règle.

​
Utiliser des délais explicites lors des appels API

Lorsque vous appelez des API ou accédez à des services externes, pensez à spécifier des délais d’attente explicites. La valeur spécifique du délai d’attente que vous choisissez varie généralement en fonction de votre cas d’utilisation, mais en général, il est conseillé de choisir une valeur aussi basse que possible, tout en gardant à l’esprit les caractéristiques de performance du service externe. Que vous choisissiez d’utiliser des délais explicites ou un traitement implicite, veillez toujours à répondre aux conditions d’erreur et/ou d’exception qui peuvent survenir à la suite de l’expiration d’un délai. Pour en savoir plus, consultez Meilleures pratiques en matière de traitement des erreurs.

​
Réduit les appels vers Auth0

Lorsque vous dépassez vos limites anti-attaques, vous devez réduire le nombre d’appels que vous passez à Auth0. Les spécificités dépendent de votre cas d’utilisation, mais voici quelques recommandations :
  • Réponses /.well-known/* en cache : Ces informations ne changent pas fréquemment, vous pouvez donc généralement les mettre en cache pour réduire le nombre de fois où vous devez appeler Auth0.
  • Envisagez de demander un id_token au lieu d’appeler /userinfo pour obtenir des informations sur l’utilisateur.
  • Réduisez les appels groupés, tels que « bulk delete » ou « bulk unlock ».

​
En savoir plus