Skip to main content
Les politiques personnalisées de limite de débit sont offertes dans tous les environnements de cloud public.
Les politiques personnalisées de limite de débit vous permettent de définir des plafonds de requêtes par application pour les appels de votre tenant à l’API d’authentification. Lorsqu’une application appelle Auth0 (pour demander des jetons, démarrer des flux d’autorisation ou actualiser des identifiants), chaque requête est comptabilisée dans la limite configurée pour cette application. Si une application dépasse son plafond en raison d’un bogue, d’une boucle de tentatives ou d’un comportement inattendu, Auth0 limite son débit avant qu’elle ne puisse consommer la capacité partagée de limite de débit de votre tenant. Vous pouvez appliquer des politiques personnalisées de limite de débit aux applications de première partie comme aux applications tierces dont vous ne contrôlez pas directement le comportement.
Les politiques personnalisées de limite de débit constituent des plafonds de sécurité, et non des mécanismes de répartition de capacité. Elles ne visent pas à répartir uniformément la limite de débit totale de votre tenant entre les applications. Définissez-les assez haut pour que le trafic normal ne les déclenche jamais, mais assez bas pour qu’une application défaillante soit détectée avant d’avoir une incidence sur votre tenant.

​
Comment les limites de débit personnalisées s’articulent avec les limites de débit du tenant

Votre tenant dispose d’une limite de débit globale d’authentification établie selon votre forfait d’abonnement. Les politiques de limite de débit personnalisées ajoutent un plafond par application, inférieur à cette limite globale. Les deux niveaux fonctionnent de concert :
  • Chaque requête qui réussit la vérification de la limite de débit personnalisée est tout de même comptabilisée dans la limite de débit globale de votre tenant.
  • Si une application dépasse sa limite personnalisée, Auth0 lui renvoie le code HTTP 429. La requête rejetée n’est pas comptabilisée dans la limite de débit globale de votre tenant.
  • Si la limite globale de votre tenant est atteinte en premier, toutes les applications sont limitées, même si elles respectent leurs limites personnalisées.
Les limites de débit personnalisées empêchent des applications individuelles de consommer une part disproportionnée de la capacité globale de votre tenant. Elles n’augmentent pas son débit total.

​
Fonctionnement de l’évaluation des politiques

Auth0 évalue les politiques personnalisées de limite de débit selon une hiérarchie stricte, de la plus spécifique à la plus générale. Le premier niveau correspondant est appliqué, et tous les niveaux plus généraux sont ignorés.
  1. ID client : Politique ciblant une application précise à l’aide de son ID client. Si une politique correspondante existe, l’évaluation s’arrête ici.
  2. Groupe : Profils regroupés (comme les applications tierces ou CIMD) auxquels s’applique une seule limite partagée pour le trafic combiné de toutes les applications du groupe. Toutes les applications du groupe utilisent la même politique. Il n’y a aucune répartition par application au sein du groupe. Si l’application appartient à un groupe doté d’une politique, l’évaluation s’arrête ici.
  3. Globale / Par défaut : Politique de solution de secours qui s’applique à toute application non couverte par une politique d’ID client ou de groupe. Chaque application dispose de sa propre politique indépendante à la limite configurée. La limite est partagée, mais les politiques ne le sont pas. Cela signifie que chaque application est évaluée séparément selon le même plafond.
Cette hiérarchie protège à la fois contre les applications individuelles qui se comportent mal et les hausses de trafic globales provenant de catégories entières d’applications.

​
Compteurs communs (Politiques de groupe)

Les politiques de groupe utilisent un seul compteur commun pour toutes les applications du groupe. Chaque requête provenant d’un membre du groupe puise dans le même bucket. Par exemple, si vous créez une politique de groupe appelée « Clients tiers » avec une limite de 100 RPS et que le groupe contient cinq applications, la limite de 100 RPS s’applique à leur trafic combiné. Si une application envoie 90 RPS et que les autres en envoient 5 RPS chacune, le groupe atteint sa limite (90 + 5 + 5 + 5 + 5 = 110 RPS). Auth0 limite les requêtes suivantes provenant de n’importe quelle application du groupe. Aucune allocation par application n’est garantie au sein du groupe. Si une application tierce nécessite un traitement différent, attribuez-lui une politique d’ID client, qui prévaut sur la limite du groupe.

​
Applications tierces et clients CIMD

Bien que les applications enregistrées à l’aide du ID client Metadata Document (CIMD) soient techniquement des applications tierces, Auth0 les classe dans un groupe distinct de celui des applications tierces traditionnelles. Il existe donc deux groupes distincts :
  • Applications tierces (préfixe d’ID client : tpa_) : applications tierces traditionnelles, y compris celles créées au moyen de la Management API ou de Dynamic Client Registration (DCR).
  • Clients CIMD (préfixe d’ID client : https://) : applications créées au moyen de ID client Metadata Document.
Chaque groupe possède son propre compteur commun. Le trafic provenant des clients CIMD n’est pas pris en compte dans la limite du groupe des applications tierces, et vice versa. Vous pouvez déterminer à quel groupe appartient une application grâce au préfixe de son ID client.

​
Compteurs indépendants (politiques globales/par défaut)

Les politiques globales utilisent des compteurs indépendants. Chaque application possède son propre compteur, évalué en fonction du même plafond configuré. Les applications ne se font pas concurrence pour la capacité. Par exemple, si vous définissez une politique globale par défaut de 50 RPS : l’application A peut envoyer 50 RPS, l’application B peut envoyer 50 RPS et l’application C peut envoyer 50 RPS, chacune indépendamment. Le fait que l’application A atteigne sa limite n’a aucune incidence sur les applications B ou C. Une application n’est limitée que lorsqu’elle dépasse elle-même 50 RPS. Utilisez les politiques de groupe lorsque vous devez plafonner la charge globale provenant d’une catégorie d’applications (comme des intégrations tierces dont le trafic combiné pourrait surcharger votre tenant). Utilisez la politique globale par défaut lorsque vous avez besoin d’un plafond de sécurité uniforme par application, sans coordination entre elles.

​
Requêtes prises en compte dans les limites de débit personnalisées

Les politiques de limite de débit personnalisées comptabilisent les requêtes de l’API d’authentification associées au client_id d’une application. Auth0 comptabilise une requête lorsque l’application contrôle si elle est effectuée et à quelle fréquence, même si le navigateur de l’utilisateur final est le client HTTP qui l’envoie.

​
Exclusions des limites de débit personnalisées

Une fois qu’Auth0 lance un flux d’authentification (après /authorize), le navigateur de l’utilisateur final interagit directement avec Auth0 pour terminer la connexion. Ces requêtes suivantes (affichage de la page de connexion, envoi des identifiants, exécution des vérifications MFA) ne sont pas prises en compte dans les limites de débit personnalisées. L’application n’est pas à l’origine de ces requêtes et ne peut en contrôler ni la fréquence ni le moment. Par exemple, dans un flux de connexion typique :
  1. Votre application redirige l’utilisateur vers /authorize → comptabilisée (votre application en est à l’origine).
  2. Auth0 affiche la page de connexion → non comptabilisée (du navigateur vers Auth0, hors du contrôle de votre application).
  3. L’utilisateur envoie ses identifiants → non comptabilisée.
  4. L’utilisateur effectue une vérification MFA → non comptabilisée.
  5. Auth0 redirige l’utilisateur avec un code d’autorisation → non comptabilisée.
  6. Votre application échange le code à /oauth/token → comptabilisée (votre application en est à l’origine).
Comme les requêtes lancées par le navigateur sont exclues, les politiques de limites de débit personnalisées réduisent, sans toutefois éliminer, le risque d’attaques qui épuisent les limites de débit de l’ensemble du tenant en déclenchant des flux d’authentification complets. Pour vous protéger contre ces types d’attaques, consultez Protection contre les attaques.

​
Mode journalisation uniquement

Lorsque vous activez le mode journalisation uniquement pour une politique, Auth0 surveille les requêtes par rapport à la limite configurée et génère des événements de journal api_limit avec action: log, sans toutefois renvoyer de réponses HTTP 429. Le trafic continue de circuler normalement. Utilisez le mode journalisation uniquement pour :
  • Valider qu’une nouvelle limite est adéquatement définie avant de bloquer le trafic.
  • Identifier les applications qui seraient touchées par une modification de politique.
  • Établir des profils de trafic de référence pour une application ou un groupe.
Vous pouvez à tout moment faire passer une politique du mode journalisation uniquement au mode appliqué, ou inversement, sans avoir à la recréer.

​
Choisir une valeur de limite de débit

La limite appropriée dépend de votre contrôle sur les schémas de trafic de l’application.

​
Applications de première partie (politiques d’ID client)

Pour les applications que vous possédez et exploitez, vous pouvez mesurer directement le trafic :
  1. Activez le mode journalisation uniquement dans la politique.
  2. Observez les tendances des requêtes de l’application pendant 3 à 7 jours.
  3. Examinez les événements de journal api_limit afin d’identifier les taux de requêtes de pointe.
  4. Fixez la limite à 2 à 3 fois le pic observé. Par exemple, si une application atteint un pic de 10 RPS, fixez sa limite entre 20 et 30 RPS.
Comme vous contrôlez le code de l’application, vous pouvez anticiper l’évolution du trafic et ajuster la limite de manière proactive lorsque vous déployez des changements qui augmentent le volume de requêtes.

​
Applications tierces (politiques de groupe ou globales)

Pour les applications que vous ne contrôlez pas, comme les intégrations de partenaires, les applications créées par des clients ou les connecteurs du Marketplace, vous ne pouvez pas prévoir les habitudes de trafic à l’avance. Définissez des limites en fonction de ce que votre tenant peut absorber en toute sécurité :
  1. Calculez le nombre maximal de RPS que votre tenant peut tolérer d’une seule source sans nuire aux autres applications.
  2. Fixez la limite à ce seuil ou en deçà.
  3. Activez le mode journalisation uniquement pour valider la limite par rapport au trafic réel avant de l’appliquer.
  4. Surveillez les événements api_limit et ajustez les limites à mesure que les habitudes d’utilisation des applications tierces se dessinent.
Comme vous ne pouvez pas contrôler le moment où les applications tierces modifient leur comportement, considérez ces limites comme des plafonds de protection plutôt que comme des cibles de performance.
L’objectif est d’établir un plafond que le trafic normal n’atteint jamais. Si une application approche régulièrement de sa limite, celle-ci est trop basse. Augmentez-la et examinez les habitudes de trafic.

​
Bloquer entièrement une application

Définir une limite de débit personnalisée à 0 bloque immédiatement toutes les requêtes de l’API d’authentification provenant de cette application, sans consommer de capacité de limite de débit. Utilisez cette option pour mettre hors service une application compromise ou qui présente de graves dysfonctionnements pendant que vous enquêtez.

​
Créer une politique personnalisée de limite de débit

Pour créer une politique personnalisée de limite de débit à l’aide de la Management API, envoyez une requête POST /api/v2/rate-limit-policies avec un jeton de la Management API doté de la portée create:rate_limit_policies.
Définissez une limite de débit pour une application précise à l’aide de son ID client. Il s’agit du niveau de politique le plus précis, qui prévaut sur les politiques de groupe et globales.
Vous utilisez Auth0 CLI ? Si ce n’est pas déjà fait, configurez et authentifiez votre session CLI avant d’exécuter cette commande.
Pour activer le mode journalisation uniquement plutôt que d’appliquer la limite, définissez action sur "log". Auth0 comptabilise les requêtes par rapport à la limite et génère des événements de journal api_limit, mais ne renvoie pas de réponses HTTP 429.

​
Surveiller à l’aide des journaux

Utilisez les journaux du tenant pour observer l’incidence des politiques personnalisées de limite de débit sur le trafic : Auth0 émet ces événements de journal au plus une fois par minute pour chaque combinaison de politique et d’application. Si une application dépasse continuellement sa limite, vous verrez un événement api_limit par minute plutôt qu’un événement pour chaque requête rejetée. Cela empêche le volume de journaux d’augmenter pendant une surcharge prolongée. Pour afficher ces événements, accédez à Auth0 Dashboard > Monitoring > Logs et filtrez par type d’événement. Pour en savoir plus sur les champs des événements de journal, consultez Codes de type d’événement de journal.
Le type d’événement api_limit est utilisé à la fois pour les politiques personnalisées de limite de débit et les limites de débit globales de votre tenant. Pour identifier les événements déclenchés par une politique personnalisée, consultez les détails de l’événement de journal afin d’y trouver le nom de la politique et le client_id cible. Les événements liés aux limites de débit globales ne comprennent pas de nom de politique.Activez le mode de journalisation uniquement pour les nouvelles politiques afin d’observer leur incidence sans bloquer le trafic. Consultez les journaux après 3 à 7 jours, puis activez l’application de la limite une fois que vous avez confirmé qu’elle est correctement configurée.

​
Surveiller au moyen des en-têtes de réponse HTTP

Auth0 renvoie un en-tête de réponse Auth0-RateLimit pour toutes les requêtes évaluées par une politique personnalisée de limite de débit. Cet en-tête est propre aux politiques personnalisées de limite de débit et indique l’état actuel du quota de l’application :
Lorsqu’une application dépasse sa limite de débit personnalisée, Auth0 renvoie une réponse HTTP 429 Too Many Requests avec un en-tête Retry-After indiquant le nombre de secondes à attendre avant de réessayer. Le corps de la réponse contient une erreur JSON :
Pour les requêtes /authorize, Auth0 ne renvoie pas de réponse d’erreur JSON, car elles proviennent d’une redirection du navigateur. Auth0 affiche plutôt une page d’erreur directement à l’utilisateur. Si vous activez l’option Redirect dans la politique, Auth0 redirige l’utilisateur vers une URL configurée au lieu d’afficher la page d’erreur. La limitation s’applique uniquement à l’application qui a dépassé sa limite. Les autres applications du même tenant ne sont pas touchées.
Les en-têtes X-RateLimit-* (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) reflètent la limite de débit globale de votre tenant, et non la limite de la politique personnalisée. Ces en-têtes apparaissent dans les réponses réussies et les réponses soumises à une limitation, mais indiquent toujours la capacité à l’échelle du tenant. Utilisez l’en-tête Auth0-RateLimit pour surveiller la consommation du quota de la politique personnalisée.

​
En savoir plus