Cas d’utilisation des limites de débit

Comment déterminer si vous êtes soumis à une limite de débit

​

Découvrez quand les requêtes adressées à un locataire sont soumises à une limite de débit

Il existe plusieurs façons de déterminer si Auth0 applique une limite de débit à un produit client. Consultez ci-dessous les causes possibles de cette limite de débit.

​

Journaux du locataire

En vous abonnant à différents journaux du locataire, vous pouvez surveiller les problèmes liés au volume des requêtes. Pour comprendre le fonctionnement des journaux des événements du locataire 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 d’une limite de débit dans le réservoir global de limitation du débit pour Authentication ou la Management API. Si le nombre de jetons de requête utilisés demeure supérieur à 80 % après une minute pour ce même réservoir de limitation du débit, une deuxième entrée de journal d’avertissement est générée. Si une limite de débit est dépassée pour un autre réservoir de limitation du 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 essentielle pour diagnostiquer la cause sous-jacente.

​

api_limit_warning

L’entrée de journal api_limit_warning est déclenchée lorsque le taux 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 reste supérieur à 80 % après une minute pour le même réservoir de limite de débit, une deuxième entrée d’avertissement est générée. Si le seuil de 80 % est dépassé pour un autre réservoir de limite de débit, une nouvelle entrée api_limit_warning est créée.

​

appi (Public Performance Burst uniquement)

Le journal appi est généré lorsqu’un locataire client doté du module complémentaire Public Performance Burst dépasse la limite soutenue de 100 RPS pour les requêtes adressées à l’API d’authentification, ce qui consomme un bloc d’une minute de son allocation de rafale sur 48 heures. Si, après 15 minutes, le taux de requêtes dépasse de nouveau cette limite soutenue de 100 RPS, un deuxième journal appi est généré.

​

Réponses de l’API

Les réponses de l’API Auth0 renvoient des réponses HTTP 429 (Too Many Requests) lorsqu’une limite de débit est dépassée. Cela permet aux clients de surveiller l’application des limites de débit en temps réel. Toutefois, cela n’est utile que pour les applications personnalisées qui interagissent directement avec l’API Auth0.

​

Gestion des erreurs du SDK

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

​

Pages d’erreur

La réponse de page d’erreur est renvoyée pour les points de terminaison qui génèrent du contenu HTML pour l’utilisateur final. Si votre locataire 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 locataire 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 les descriptions de Affected endpoints et de JSON Error.

​

Découvrez pourquoi les requêtes d’un locataire font l’objet d’une limite de débit

Si vous pensez que les requêtes du locataire font l’objet d’une limite de débit et que vous avez besoin d’aide pour en comprendre la raison, ouvrez une demande par l’intermédiaire du Support Center.  Dans votre demande, veuillez inclure le journal brut complet dans lequel le problème a été observé.

​

Prévoir quand les requêtes adressées à un locataire feront l’objet d’une limite de débit

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 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é en requêtes supplémentaires.
• x-ratelimit-reset : Horodatage UNIX, en secondes, indiquant l’heure prévue à laquelle des requêtes supplémentaires seront ajoutées au réservoir.

Par exemple :

Une API a la limite de débit suivante :

• Limite de rafale : 1000
• Limite de débit soutenu : 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 soutenu 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-headers 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 locataire a utilisé 950 des 1000 requêtes autorisées pour cette API, et il ne lui reste que 50 requêtes avant l’ajout de nouvelles requêtes.
• De nouvelles requêtes seront ajoutées à 1675452600, soit à 19 h 30 min 00 s 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, une limitation de débit est à prévoir. Le moment où elle s’appliquera dépend de la limite de rafale et de l’ampleur du dépassement de 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 soutenu : 10 requêtes par seconde.

Points clés :

• L’API commence avec cinq jetons de requête et ne dépassera jamais ce nombre, ce qui correspond à la limite de rafale.
• Le réservoir de 10 jetons est rempli de nouveau chaque seconde, selon une « fenêtre fixe ». De nouveaux jetons sont ajoutés au réservoir, qui est 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 septième à 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 démarre avec cinq jetons de requête, ce qui correspond à la limite de rafale.
• Le réservoir de six jetons est rempli de nouveau chaque minute, au moyen d’une « fenêtre fixe ». De nouveaux jetons sont ajoutés au réservoir, qui est ainsi réapprovisionné 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 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 remplit de nouveau le réservoir de jetons en raison de l’algorithme de fenêtre fixe. Par conséquent, les requêtes 7 à 11 réussissent, et la 12e épuise le réservoir, ce qui entraîne une erreur 429.
• T+2min : Auth0 remplit de nouveau le réservoir de jetons, et la requête suivante (13) reçoit une réponse 200.

​

Autres scénarios

Il arrive parfois qu’Auth0 attribue deux limites de débit à une même API. Cela permet de configurer une limite de rafale et une limite de débit soutenu mieux adaptée aux besoins du service. En pratique, la première limite de débit devient la limite de rafale effective, et la seconde limite de débit devient la limite de débit soutenu effective. Dans ce scénario, Auth0 publie uniquement les limites de rafale et de débit soutenu effectives, plutôt que de communiquer les limites de rafale et de débit soutenu réelles.

​

Utilisation de l’API pour la connexion et l’inscription des utilisateurs finaux

Il existe quelques 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 API vers les points de terminaison de l’API d’authentification afin de déterminer si cet utilisateur est autorisé à recevoir un jeton d’autorisation et, par conséquent, à accéder à l’application demandée.

Le nombre exact d’appels API dépend de quelques configurations :

• Expérience d’authentification (p. ex., nouveau Universal Login ou Classic Login)
• Flux d’authentification (p. ex., connexion, inscription ou changement de mot de passe)
• Type de flux d’authentification (p. ex., connexion avec nom d’utilisateur et mot de passe; connexion au moyen d’un fournisseur social; connexion lorsqu’un jeton d’authentification existe déjà)

Ci-dessous, nous décrivons certaines configurations client courantes et leur incidence sur l’utilisation de l’API.

​

Universal Login

Auth0 Universal Login offre la fonctionnalité essentielle d’un serveur d’autorisation : le flux 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.

Flux d’authentification	Type de flux	Requêtes vers les points de terminaison de l’API d’authentification
Connexion	Défi de nom d’utilisateur/mot de passe*	5
Connexion	Fournisseur d’identité tiers – p. ex., connexion sociale ou d’entreprise	6
Connexion	Session d’authentification Auth0 existante	1
Inscription	au moyen d’un nom d’utilisateur/mot de passe	6

​

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 :

Modificateur	Description	Requêtes supplémentaires
ID First	Identifie l’utilisateur avant de demander les identifiants de connexion.	+2
MFA	Ajoute l’authentification multifacteur.	+2 par facteur
OTP	Mot de passe à usage unique pour l’authentification	+2
Enterprise Login	Authentification par l’intermédiaire d’une connexion d’entreprise (p. ex., SAML, OIDC, LDAP).	+1
Client Credentials	Utilisé pour l’authentification machine à machine. S’applique dans tous les cas, même si des Actions sont utilisées.	+1

*Tout élément utilisé en combinaison s’ajoute au nombre total de requêtes.

​

Connexion classique

Connexion classique est une expérience de connexion hébergée par Auth0 qui s’appuie sur JavaScript pour la personnalisation. Mettre en œuvre la connexion classique est moins complexe que d’intégrer directement le processus d’authentification à votre application, et cela peut aider à réduire les risques liés à l’authentification inter-origines.

Flux d’authentification	Type de flux	Requêtes
Connexion	Authentification par nom d’utilisateur et mot de passe	8
Connexion	Fournisseur d’identité tiers – p. ex. connexion sociale ou d’entreprise	8
Connexion	Session d’authentification Auth0 existante	2
Inscription	Nom d’utilisateur/mot de passe	8

Les clients qui configurent des bases de données personnalisées doivent ajouter deux (2) appels supplémentaires à l’API d’authentification à chaque flux d’authentification décrit ci-dessus. Pour en savoir plus, consultez Connexions de base de données personnalisées.

​

Facteurs

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

Facteur	Description	Requêtes supplémentaires
Authentification par SMS uniquement	Lorsque le SMS est utilisé comme méthode d’authentification principale.	+7
Connexion sociale native	Connexion à l’aide d’un fournisseur social natif (p. ex., Google, Facebook).	+1
Redirections	Des redirections supplémentaires pendant l’authentification augmentent le nombre de requêtes.	+1