Skip to main content

​
Déterminez quand les requêtes vers un tenant sont soumises à une limitation de débit

Il existe plusieurs façons de déterminer si le produit d’un client est soumis à une limitation de débit par Auth0. Consultez ci-dessous les causes possibles de cette limitation.

​
Logs du tenant

En vous abonnant à différents logs du tenant, vous pouvez suivre les problèmes liés aux volumes de requêtes. Pour comprendre le fonctionnement des logs d’événements du tenant et des opérations dans Auth0, consultez Logs.

​
api_limit

L’événement api_limit est déclenché immédiatement après le dépassement de la limite de débit du réservoir de limite de débit global pour l’authentication ou l’. Si une limite de débit est dépassée pour un autre réservoir de limite de débit, un nouvel événement api_limit est généré. Cela aide les clients à déterminer quelle configuration de limite de débit leurs appels d’API déclenchent, ce qui constitue une première étape cruciale pour diagnostiquer la cause profonde.

​
api_limit_warning

Le journal api_limit_warning est déclenché lorsque le débit de requêtes d’un client consomme 80 % des jetons de requête d’un réservoir de limite de débit donné. Si le nombre de jetons de requête utilisés demeure supérieur à 80 % après une minute pour le même réservoir de limite de débit, un deuxième journal d’avertissement est généré. Si le seuil de 80 % est dépassé pour un autre réservoir de limite de débit, un nouveau journal api_limit_warning est créé.

​
appi (Public Performance Burst uniquement)

Le log appi est déclenché lorsqu’un tenant client doté de l’add-on Public Performance Burst dépasse la limite soutenue de 100 RPS pour les requêtes à l’Authentication API, ce qui consomme un bloc d’une minute de son allocation de burst de 48 heures. Si, après 15 minutes, le taux de requêtes dépasse de nouveau la limite soutenue de 100 RPS, un deuxième log appi est déclenché.

​
Réponses de l’API

Les réponses de l’Auth0 API renvoient une réponse HTTP 429 (Trop de requêtes) lorsque la limite de requêtes est dépassée. Cela permet aux clients d’observer l’application des limites de requêtes en temps réel. Toutefois, cela n’est utile que pour les applications clientes personnalisées qui interagissent directement avec l’Auth0 API.

​
Gestion des erreurs du SDK

Si vous utilisez un SDK, consultez les pages d’erreurs des bibliothèques SDK de la Management API.

​
Pages d’erreur

Une réponse sous forme de page d’erreur est renvoyée pour les points de terminaison qui affichent du contenu HTML à l’utilisateur final. Si votre tenant est configuré pour utiliser des pages génériques (hébergées par Auth0), Auth0 affiche la page d’erreur au lieu du contenu attendu lorsque vous dépassez la limite de réponse.  Si votre tenant est configuré pour utiliser des pages d’erreur personnalisées, l’utilisateur est redirigé vers l’URL de la page d’erreur personnalisée avec l’erreur correspondante dans le paramètre de chaîne de requête error_description.  Pour en savoir plus, consultez Points de terminaison concernés et les descriptions de JSON Error.

​
Découvrez pourquoi un tenant est soumis à une limitation de débit

Si vous pensez que les requêtes du tenant sont soumises à une limitation de débit et que vous avez besoin de soutien pour en comprendre la raison, ouvrez une requête dans le Support Center.  Dans votre requête, veuillez inclure le journal brut complet dans lequel le problème a été constaté.

​
Prévoir quand les requêtes adressées à un tenant seront limitées

Auth0 fournit des renseignements à jour sur l’état actuel de vos limites de débit au moyen des en-têtes de réponse HTTP provenant des points de terminaison pour lesquels des politiques de limite de débit sont configurées. Cet état est communiqué comme suit :
  • x-ratelimit-limit: Nombre maximal de requêtes disponibles.
  • x-ratelimit-remaining: Nombre de requêtes restantes jusqu’à ce que le réservoir soit réapprovisionné avec des requêtes supplémentaires.
  • x-ratelimit-reset: horodatage UNIX, en secondes, du moment prévu où des requêtes supplémentaires seront ajoutées au réservoir.
Par exemple : Une API a la limite de débit suivante :
  • Limite en rafale : 1000
  • Limite de débit soutenue : 100 requêtes par seconde (sur une fenêtre fixe)
À partir de ces renseignements, vous pouvez déduire ce qui suit :
  • La limite de débit soutenue est de 100 requêtes par seconde sur une fenêtre fixe.
  • En raison de la fenêtre fixe, le réservoir de requêtes est réapprovisionné chaque seconde.
Si vous recevez les x-en-têtes suivants dans la réponse de votre API :
  • x-ratelimit-limit: 1000
  • x-ratelimit-remaining: 50
  • x-ratelimit-reset: 1675452600
Vous savez maintenant que :
  • Votre tenant a utilisé 950 des 1000 requêtes autorisées pour cette API, et il ne lui reste que 50 requêtes avant que des requêtes supplémentaires soient ajoutées.
  • De nouvelles requêtes seront ajoutées à 1675452600, soit à 19:30:00 UTC le 3 février 2023.
  • 1 nouvelle requête sera ajoutée à ce moment-là
Par conséquent, si vous effectuez des requêtes à un rythme supérieur à celui décrit ci-dessus, il faut vous attendre à une limitation du débit. Le délai avant que vos requêtes soient limitées dépend de la limite en rafale et de la mesure dans laquelle vous dépassez la limite soutenue.

​
Exemples d’application des limites de débit

​
Exemple de requêtes par seconde

Supposons qu’Auth0 lance une nouvelle API appelée /ratelimitexample avec les valeurs de limite de débit suivantes :
  • Limite de rafale : cinq (5) requêtes
  • Limite de débit soutenue : 10 requêtes par seconde.
Points clés :
  • L’API dispose au départ de cinq jetons de requête et n’en dépassera jamais cinq, ce qui correspond à la limite de rafale.
  • Le réservoir de 10 jetons est rechargé chaque seconde selon une « fenêtre fixe ». De nouveaux jetons sont ajoutés au réservoir, qui est ainsi rempli de nouveau au début de chaque seconde.
 Exemple de scénario avec des limites de débit :
Dans ce scénario :
  • T0 - T1sec :  L’utilisateur final effectue six requêtes pendant la première seconde. Cinq requêtes — soit la limite de rafale — reçoivent une réponse 200. La sixième requête reçoit une erreur 429 parce qu’il ne reste plus de jetons de requête dans le réservoir.
  • T1sec - T2sec :  Auth0 remplit de nouveau le réservoir de jetons de requête en raison de l’algorithme de fenêtre fixe. Par conséquent, les 7e à 11e requêtes réussissent, ce qui vide le réservoir à la 12e requête et entraîne une erreur 429.
  • T2sec - T3sec :  Auth0 remplit de nouveau le réservoir de jetons, et la requête suivante (13) reçoit une réponse 200.

​
Exemple de requêtes par minute

Supposons qu’Auth0 lance une nouvelle API appelée /ratelimitexample2 avec les valeurs de limite de débit suivantes :
  • Limite de rafale :  Cinq (5) requêtes
  • Limite de débit soutenue :  Six (6) requêtes par minute.
Points clés :
  • L’API commence avec cinq jetons de requête, ce qui correspond à la limite de rafale.
  • Le réservoir de six jetons est rechargé chaque minute, selon une « fenêtre fixe ». De nouveaux jetons sont ajoutés au réservoir, qui est de nouveau rempli au « début » de chaque minute.
Exemple de scénario avec des limites de débit :
Dans ce scénario :
  • T0 - T+1min :  L’utilisateur final effectue six requêtes pendant la première minute. Cinq requêtes – soit l’équivalent de la limite de rafale – reçoivent une réponse 200.  La sixième requête reçoit une erreur 429, car il ne reste plus de jetons de requête.
  • T+1min - T+2min :  Auth0 recharge le réservoir de jetons en raison de l’algorithme de fenêtre fixe. Par conséquent, les requêtes 7 à 11 réussissent, ce qui vide le réservoir à la 12e requête et entraîne une erreur 429.
  • T+2min : Auth0 recharge de nouveau le réservoir de jetons, et la requête suivante (13) reçoit une réponse 200.

​
Autres scénarios

À l’occasion, Auth0 attribue deux limites de débit à une seule API.  Cela permet de configurer une limite de rafale et une limite de débit soutenu mieux adaptées aux besoins du service.  En pratique, la première limite de débit devient la limite de rafale effective, et la deuxième limite de débit devient la limite de débit soutenu effective.  Dans ce scénario, Auth0 publie uniquement les limites effectives de rafale et de débit soutenu, plutôt que de communiquer les limites réelles de rafale et de débit soutenu.

​
Utilisation de l’API de connexion et d’inscription pour les utilisateurs finaux

Il existe plusieurs flux d’authentification, notamment la connexion, l’inscription et le changement de mot de passe. Les plus courants sont généralement la connexion, suivie de l’inscription. La connexion d’un utilisateur final déclenche plusieurs appels d’API vers des point de terminaison de l’Authentication API afin de déterminer si l’utilisateur final est autorisé à recevoir un jeton d’autorisation et, par conséquent, à accéder à l’application demandée. Le nombre exact d’appels d’API dépend de plusieurs configurations :
  • Expérience d’authentification (p. ex., nouveau ou Classic Login)
  • Flux d’authentification (p. ex., connexion, inscription ou changement de mot de passe)
  • Type de flux d’authentification (p. ex., connexion par nom d’utilisateur / mot de passe; connexion avec Social Login; connexion lorsqu’un jeton d’authentification existe déjà)
Ci-dessous, nous décrivons quelques configurations client courantes et leur incidence sur l’utilisation de l’API.

​
Universal Login

Auth0 Universal Login fournit la fonctionnalité essentielle d’un  : le processus de connexion. Lorsqu’un utilisateur doit prouver son identité pour accéder à votre application, vous pouvez le rediriger vers Universal Login et laisser Auth0 gérer le processus d’authentification.

​
Modificateurs

Certaines configurations d’authentification modifient le nombre de requêtes de base. Ces ajustements dépendent de mesures de sécurité supplémentaires ou de flux d’authentification : *Tout élément utilisé en combinaison s’ajoute au nombre total de requêtes.

​
Classic Login

Classic Login est une expérience de connexion hébergée par Auth0 qui repose sur JavaScript pour la personnalisation. La mise en œuvre de Classic Login est moins complexe que l’intégration directe du processus d’authentification dans votre application et peut aider à prévenir les risques liés à l’authentification inter-origines.
Les clients qui configurent des Custom Databases doivent ajouter deux (2) appels supplémentaires à l’Authentication API pour chaque flux d’authentification décrit ci-dessus. Pour en savoir plus, consultez Custom Database Connections.

​
Modificateurs

Les facteurs suivants augmentent le nombre de requêtes pour Classic Login :