Cas d’utilisation des limites anti-attaques

Il existe plusieurs façons de déterminer si le produit d’un client est soumis à une limite anti-attaques de la part d’Auth0. Vous trouverez ci-dessous les causes possibles des limites anti-attaques.

, lire Logs (Journaux).

L’événement api_limit est déclenché immédiatement après le dépassement d’une limite anti-attaques pour un compartiment donné. Si la limite anti-attaques est toujours dépassée après une minute pour le compartiment donné, un deuxième journal est créé. Si une limite anti-attaques est dépassée pour un autre compartiment, un nouvel événement api_limit est créé. Cela permet aux clients d’identifier la configuration de limite anti-attaques déclenchée par leurs appels d’API, ce qui constitue une première étape essentielle pour diagnostiquer la cause première.

Le journal api_limit_warning est déclenché lorsque le taux de requêtes d’un client consomme 80 % des jetons de requête pour un compartiment de limite anti-attaques donné. Si le nombre de jetons de requête utilisés reste supérieur à 80 % après une minute pour le même compartiment de limite anti-attaques, un deuxième journal d’avertissement est créé. Si le seuil de 80 % est dépassé pour un compartiment de limite anti-attaques différent, un nouveau journal api_limit_warning est créé.

Le journal appi est déclenché lorsqu’un locataire client doté d’un module complémentaire Public Performance Burst dépasse sa limite anti-attaques de requêtes Authentication API soutenue de 100 RPS, consommant ainsi un bloc de 15 minutes de son allocation de 48 heures. de rafale. Si, après 15 minutes, le débit de requêtes dépasse à nouveau la limite de 100 RPS, un deuxième journal appi est déclenché.

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

Si vous utilisez une trousse SDK, reportez-vous aux pages d’erreur des bibliothèques de trousse SDK pour Management API.

La réponse de la page d’erreur est envoyée pour les points de terminaison qui rendent le contenu HTML à 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éponses.  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 pertinente 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 des Erreurs JSON.

Contactez le Centre d’assistance si les requêtes des locataires sont soumises à des limites anti-attaques et que vous souhaitez en connaître les raisons.  Veuillez inclure le journal brut complet où le problème a été constaté dans la demande.

Auth0 fournit des informations actualisées sur l’état actuel de vos limites anti-attaques en utilisant les en-têtes de réponse HTTP des points de terminaison concernés par des limites anti-attaques. Cet état est communiqué comme suit :

• x-ratelimit-limit : nombre maximum de requêtes disponibles.

• x-ratelimit-remaining : nombre de requêtes restantes disponibles jusqu’à ce que le compartiment reçoive des requêtes supplémentaires.

• x-ratelimit-reset : UNIX timestamp, en secondes, de l’heure à laquelle des demandes supplémentaires seront ajoutées.

Par exemple :

La limite anti-attaques suivante s’applique à une API :

• Limite de charge subite : 1000

• Limite anti-attaques appliquée : 100demandes par seconde (pour une période fixe).

De ces informations, vous pouvez déduire :

• La limite anti-attaques appliquée est de 100 requêtes par seconde pour une période fixe.

• En raison de la fenêtre fixe, le compartiment des requêtes est rempli toutes les secondes.

Si vous recevez les x-headers suivants dans votre réponse API :

• x-ratelimit-limit 1000 :

• x-ratelimit-remaining 50 :

• x-ratelimit-reset 1675452600 :

Vous savez déjà que :

• Votre locataire a utilisé 950 des 1 000 requêtes autorisées pour cette API, et il ne lui reste que 50 demandes jusqu’à ce que des demandes supplémentaires soient ajoutées.

• Les nouvelles requêtes ont été ajoutées à 1675452600 ou 19:30:00 UTC le 3 février 2023.

• Une nouvelle requête sera ajoutée à ce moment-là.

Par conséquent, il faut s’attendre à une limitation anti-attaques si vous lancez des requêtes à un rythme supérieur à celui décrit ci-dessus.  Le délai dans lequel vous serez soumis à une limite anti-attaques dépend de la limite de charge subite et de la mesure dans laquelle vous dépassez la limite appliquée.

Supposons qu’Auth0 lance une nouvelle API appelée /ratelimitexample avec les valeurs de limite anti-attaques suivantes :

• Limite de charge subite : Cinq (5) requêtes

• Limite anti-attaques appliquée : 10 requêtes par seconde.

Principales étapes :

• L’API commence avec (et ne dépassera jamais) cinq jetons de requête, ce qui correspond à la limite de charge subite.

• Le compartiment de 10 jetons est rempli toutes les secondes, à l’aide d’une fenêtre fixe. De nouveaux jetons sont ajoutés au compartiment, le remplissant au « début » de chaque seconde.

Exemple de scénario avec des limites anti-attaques :

Dans ce scénario :

• T0 - T1sec. :  l’utilisateur final effectue six requêtes dans la première seconde.  Cinq requêtes - correspondant à la limite de charge subite - reçoivent une réponse de 200.  La sixième requête reçoit une erreur 429 parce qu’il n’y a plus de jetons de requête.

• T1sec - T2sec : Auth0 complète le compartiment des jetons de requête en raison de l’algorithme de fenêtre fixe. En conséquence, les septième à la 11e demandes sont réussies, épuisant le compartiment à partir de la 12e demande, ce qui entraîne une erreur 429.

• T2sec - T3sec : Auth0 remplit à nouveau le compartiment de jetons et la prochaine demande (13) reçoit une réponse 200.

Supposons qu’Auth0 lance une nouvelle API appelée /ratelimitexample avec les valeurs de limite anti-attaques suivantes :

• Limite de charge subite : Cinq (5) requêtes

• Limite anti-attaques appliquée :  Six (6) requêtes par seconde.

Principales étapes :

• L’API commence avec cinq jetons de requête, ce qui équivaut à la limite de charge subite.

• Le compartiment de six jetons est rempli toutes les minutes, à l’aide d’une fenêtre fixe. De nouveaux jetons sont ajoutés au compartiment, le remplissant au « début » de chaque minute.

Exemple de scénario avec des limites anti-attaques :

Dans ce scénario :

• T0 - T1min :  l’utilisateur final effectue six requêtes dans la première minute.  Cinq requêtes - correspondant à la limite de charge subite - reçoivent une réponse de 200.  La sixième requête reçoit une erreur 429 parce qu’il n’y a plus de jetons de requête.

• T+1min - T+2min : Auth0 remplit le compartiment des jetons en raison de l’algorithme de fenêtre fixe. En conséquence, les septième à la 11e demandes sont réussies, épuisant le compartiment à partir de la 12e demande, ce qui entraîne une erreur 429.

• T+2min : Auth0 remplit à nouveau le compartiment de jetons et la prochaine demande (13) reçoit une réponse 200.

Parfois, Auth0 affecte deux limites anti-attaques à une seule API.  Cela permet de configurer une limite de charge subite et une limite anti-attaques mieux adaptées aux besoins du service.  En effet, la première limite anti-attaques devient la limite de charge subite appliquée, et la deuxième limite anti-attaques devient la limite anti-attaques appliquée.  Dans ce scénario, Auth0 ne publie que les limites de charge subite et anti-attaques appliquées, plutôt que de communiquer les limites de charge subite et anti-attaques réelles.

Il y a une poignée de Flux d’authentification, y compris la Connexion, l’Inscription et le Changement de mot de passe.  Le plus courant est généralement la Connexion, suivi par l’Inscription.

La connexion d’un utilisateur final initie plusieurs appels API aux points 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 qu’il a demandée.

Le nombre précis d’appels API est fonction d’une poignée de configurations :

• Expérience d’authentification (p. ex., nouvelle connexion universelle ou connexion classique)

• 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 par connexion sociale; connexion lorsqu’un jeton d’authentification existe déjà)

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

La Connexion universelle Auth0 procure 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 la Connexion universelle et laisser Auth0 gérer le processus d’authentification.

Certaines configurations d’authentification modifient le nombre de demandes de base. Ces ajustements dépendent de mesures de sécurité supplémentaires ou de flux d’authentification :

*Tout ce qui est utilisé en combinaison s’ajoute aux demandes globales.

La Connexion classique est une expérience de connexion hébergée par Auth0 qui s’appuie sur JavaScript pour la personnalisation. L’implémentation d’une Connexion classique est moins complexe que l’intégration du processus d’authentification directement dans votre application, et elle peut aider à prévenir les dangers de l’authentification cross-origin.

Les facteurs suivants augmentent le nombre de demandes pour la connexion classique :