> ## Documentation Index > Fetch the complete documentation index at: https://docs-dev-feat-init-gt-translations.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Décrit la politique de limitation du débit d’Auth0. # Politique de limitation du débit Auth0 limite l’utilisation de ses services afin d’assurer des performances optimales et de se protéger contre les acteurs malveillants, les erreurs techniques ou un trafic légitime excessif.  Nous vous recommandons de consulter la façon dont Auth0 applique ces limites afin de configurer votre application pour offrir la meilleure expérience utilisateur possible. Pour connaître les limites de débit associées à votre compte, consultez [Configurations des limites de débit](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations) pour voir une matrice de toutes les politiques de limitation du débit.

Introduction aux limites de débit

Auth0 impose des limites pour protéger les services contre un volume excessif de requêtes et protéger les clients contre les interruptions ou la dégradation du service. Auth0 tient compte de plusieurs limites et, dans bien des cas, les applique, notamment : * Requêtes adressées aux environnements (Private Cloud uniquement) * Requêtes aux tenants par l’API ou un point de terminaison d’API * Limites diverses

Limites de requêtes de l’environnement (Private Cloud uniquement)

Dans Private Cloud, les limites de requêtes de l’environnement dépendent du niveau de performance de Private Cloud. Pour en savoir plus, consultez [Private Cloud for AWS](/docs/fr-ca/deploy-monitor/deploy-private-cloud/private-cloud-on-aws) ou [Private Cloud for Azure](/docs/fr-ca/deploy-monitor/deploy-private-cloud/private-cloud-on-azure). À l’heure actuelle, les limites de débit de l’environnement Private Cloud représentent la charge maximale sous laquelle le produit Auth0 respecte les SLA. Cependant, pour le moment, Auth0 n’applique ces limites et n’avise les clients que lorsqu’un tenant précis dans l’environnement dépasse les limites de débit. Dans la plupart des cas d’utilisation de Private Cloud, où les clients maintiennent un seul tenant de production, cela ne pose pas de problème; toutefois, les cas d’utilisation qui provisionnent plus d’un tenant de production devraient tenir compte de la charge prévue pour l’ensemble des tenants de l’environnement et mettre en place une surveillance supplémentaire au besoin. | Fonctionnalité | Authentication API | Toutes les autres API (y compris Management API) | | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Limites de débit du tenant | Tous les tenants consomment à partir d’une limite globale partagée à l’échelle de l’environnement pour l’API, mais la limite de débit de l’environnement constitue un plafond strict. Si la limite de l’environnement est dépassée en raison de la charge combinée de plusieurs tenants, les requêtes excédentaires feront l’objet d’une limitation du débit. | Les limites de débit du tenant sont appliquées indépendamment, et la limite de débit de l’environnement sert de seuil indiquant une dégradation potentielle des performances et un impact possible sur les SLA, mais **n’entraîne pas** directement de limitation du débit au niveau du tenant. | | Limite de débit de l’environnement dépassée (exemple) | Avec une limite d’environnement de 1500 rps, le Tenant 1 à 1400 rps et le Tenant 2 à 900 rps (2300 rps au total) feront en sorte que 800 requêtes seront limitées. | Avec une limite d’environnement de 1500 rps, le Tenant 1 à 1400 rps et le Tenant 2 à 900 rps (2300 rps au total) **n’entraîneront pas** de limitation du débit pour les tenants individuels, mais l’environnement dans son ensemble pourrait subir une baisse de performance et d’éventuels problèmes liés aux SLA. | Le dépassement d’une limite de débit de l’environnement invalide l’entente de niveau de service (SLA). Pour les considérations liées aux tests de charge de Private Cloud, consultez [Private Cloud on AWS](/docs/fr-ca/deploy-monitor/deploy-private-cloud/private-cloud-on-aws) et [Private Cloud on Azure](/docs/fr-ca/deploy-monitor/deploy-private-cloud/private-cloud-on-azure).

Limites de requêtes du tenant

Auth0 limite le nombre de requêtes pouvant être effectuées pour un tenant. Ces limites sont configurées en fonction de l’API, puis plus précisément selon les points de terminaison de chaque API.

Limites de débit des API

Auth0 limite le nombre de requêtes adressées à une API donnée, quel que soit le point de terminaison de l’API. Les limites des API peuvent varier selon : * API * Authentication * Management * Type de tenant (Production vs. Development ou Staging) * Niveau d’abonnement (Free, Essential, Professional, Enterprise Public vs. Private) Par exemple, un tenant gratuit hors production peut avoir des limites différentes de celles d’un tenant de production avec un abonnement payant. Pour connaître les configurations précises des limites de débit, consultez [Rate Limit Configurations](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations).

Requêtes utilisateur

Une seule requête d’utilisateur final (p. ex., Login ou Signup) déclenche généralement plusieurs requêtes vers les points de terminaison de l’Authentication API. Le ratio réel entre les requêtes des utilisateurs finaux et celles de l’Authentication API dépend de quelques facteurs : * Entité en cours d’authentification (p. ex., machine ou application mobile ou de bureau d’utilisateur final) * Expérience d’authentification (p. ex., nouveau Universal Login ou Classic Login) * Flux d’authentification (p. ex., Login, Signup ou Change Password) * Type de flux d’authentification (p. ex., Login au moyen d’un username / Password; Login par Social login; Login lorsqu’un token d’authentification existe déjà) Les clients qui utilisent l’Extensibilité pourraient ajouter encore plus de requêtes, non seulement à l’Authentication API, mais aussi à la Management API, selon la configuration de l’Extensibilité. Consultez [Rate Limit Use Cases](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-use-cases) pour savoir comment estimer l’incidence de votre configuration Auth0 sur votre utilisation de l’API.

Limites de débit des points de terminaison

Auth0 limite le nombre de requêtes envoyées aux points de terminaison de l’API et, dans certains cas, le nombre d’opérations sur les points de terminaison.  Les limites des points de terminaison de l’API varient aussi selon : * l’API * le type de tenant * le niveau d’abonnement Par exemple, un tenant Free hors production n’a pas les mêmes limites qu’un tenant de production avec un abonnement payant.

Ordre d’application des limites de requêtes du tenant

Lorsque des requêtes sont adressées à votre tenant, Auth0 les évalue d’abord en fonction de la limite globale de l’API, puis en fonction de la limite de débit de certains points de terminaison de l’API.

Autres limites

Limites de connexion pour les bases de données

Pour les connexions de base de données, Auth0 limite certains types de tentatives de connexion répétées selon le compte d’utilisateur et l’adresse IP. Pour protéger le bon fonctionnement général du système, Auth0 applique des limites de débit par utilisateur/mot de passe afin de réduire la charge. Le degré élevé de personnalisation d’Auth0 peut accroître le risque de dégradation du service. Les causes peuvent inclure : * Des tests de charge intensive * Des tests de performance * Du code inefficace qui amène les utilisateurs à se connecter plusieurs fois Les requêtes sont soumises à des limites, comme indiqué dans les politiques propres aux API Auth0. De plus, il existe une limite de débit pour les connexions d’un même utilisateur : si une adresse IP effectue 20 tentatives de connexion en une minute pour le même compte d’utilisateur, la limite de débit s’applique. Par la suite, Auth0 autorise 10 tentatives par minute pour cet utilisateur. Toute combinaison de tentatives de connexion réussies ou échouées compte dans cette limite. La [protection contre les attaques par force brute](/docs/fr-ca/secure/attack-protection/brute-force-protection) et la [limitation des IP suspectes](/docs/fr-ca/secure/attack-protection/suspicious-ip-throttling) d’Auth0 peuvent aussi limiter les connexions et les inscriptions, mais elles sont indépendantes des limites de débit. Pour en savoir plus sur la façon dont Auth0 détecte et gère les anomalies potentiellement malveillantes, consultez [Protection contre les attaques](/docs/fr-ca/secure/attack-protection).

Limites des messages SMS pour l’authentification multifacteur (utilisateurs finaux seulement)

Si vous tentez d’envoyer plus de 10 messages SMS à votre appareil en une heure, vous recevrez un message d’erreur indiquant que la limite de requêtes a été dépassée. Lorsque vous dépassez votre limite de messages, vous devez attendre au moins une heure après la première demande de message avant d’en demander un autre. Vous aurez droit à une tentative supplémentaire après chaque heure additionnelle écoulée.

Limites de la connexion sociale native

Les limites appliquées aux requêtes du flux de connexion sociale native sont établies d’après le corps des requêtes, selon les critères initiaux suivants : | Type de requête | Corps | | -------------------- | ---------------------------------------------------- | | `grant_type` | `urn:ietf:params:oauth:grant-type:token-exchange` | | `subject_token_type` | `http://auth0.com/oauth/token-type/apple-authz-code` |

Public Performance Burst

L’offre Public Performance Burst est un module complémentaire offert avec les abonnements Enterprise qui bonifie un déploiement Public Cloud existant. Cette offre permet d’augmenter dynamiquement la limite de requêtes de l’Authentication API jusqu’à un multiple de la limite de requêtes Enterprise par défaut de 100 RPS, pendant un maximum de 48 heures par mois. Ce module complémentaire étend uniquement les limites de requêtes de l’Authentication API et ne s’applique PAS à la Management API ni aux autres points de terminaison assujettis à des limites de débit en dehors de la portée de l’Authentication API. À l’heure actuelle, il existe trois modificateurs Public Performance Burst (2x, 3x et 4x) permettant respectivement 200, 300 et 400 RPS pour l’Authentication API pendant un maximum de 48 heures par mois. Les 48 heures sont comptabilisées et déduites du quota mensuel autorisé par tranches de 5 minutes, ce qui permet d’utiliser l’API au niveau du multiplicateur pendant 576 tranches de 5 minutes par mois. Lorsque le volume de requêtes visant l’Authentication API dépasse la valeur par défaut de 100 RPS, une tranche de 5 minutes est déduite de l’allocation mensuelle, et le trafic est autorisé au débit associé au multiplicateur. Le trafic peut demeurer dans la plage du multiplicateur pendant les 5 minutes consécutives complètes à partir de ce moment, sans entraîner de déductions supplémentaires. Il est possible de surveiller les événements de déduction de tranche au moyen des [journaux du tenant](/docs/fr-ca/deploy-monitor/logs/log-event-type-codes). Chaque déduction génère un type d’événement de journal du tenant `appi` associé contenant des renseignements sur l’allocation déjà consommée et celle qui reste. Pour en savoir plus, consultez la section Authentication API dans [Rate Limits - Enterprise](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations/enterprise-public).

Private Performance Burst

L’offre Private Performance Burst (actuellement offerte sur AWS pour les paliers 30x et 60x) comprend une capacité de performance en rafale (de pointe) allant jusqu’à 30x (3 000 RPS) ou 60x (6 000 RPS) pendant un maximum de 80 heures par mois. La capacité de base, qui correspond à la moitié de la capacité en rafale, est offerte pendant le reste du mois. Autrement dit, l’offre 30x Private Performance Burst comprend : * Capacité de base : 1 500 RPS pour tout le mois * Capacité en rafale/de pointe : 3 000 RPS pendant un maximum de 80 heures par mois Si les transactions d’authentification dépassent la limite de base des requêtes API, une heure est alors déduite de l’allocation mensuelle. Le trafic peut rester à un débit élevé pendant l’heure complète qui suit. Des déductions additionnelles sont effectuées de la même façon chaque fois que le seuil est de nouveau dépassé. Une fois l’allocation de 80 heures épuisée, le trafic d’authentification sera limité à la capacité de base jusqu’à l’entrée en vigueur de la nouvelle allocation mensuelle.

Limites de simultanéité de l’extensibilité

Afin d’assurer la disponibilité du système et une utilisation équitable de ses ressources, Auth0 limite le nombre de requêtes simultanées en cours pour l’ensemble des produits d’extensibilité : Actions, Hooks, Rules, Custom Database Connections, Extensions et les connexions Custom OAuth2. Les tenants qui dépassent leur limite de requêtes simultanées doivent s’attendre à recevoir des erreurs pour les nouvelles requêtes jusqu’à ce que les requêtes en cours soient terminées. Les limites de simultanéité sont définies ci-dessous : | Abonnement | Limite de simultanéité (par tenant) | | ----------------------------------------------------------------------- | ----------------------------------- | | Public Cloud | 250 | | Tier Dev Private Cloud | 100 | | Private Cloud Basic 100 RPS (1x) | 200 | | Private Cloud Performance 500 RPS (5x) | 400 | | Private Cloud Performance 1500 RPS (15x) | 1200 | | Private Cloud Performance 3000 RPS (30x) and 3000 RPS Burst (30x Burst) | 1200 | | Private Cloud Performance 6000 RPS (60x) and 6000 RPS Burst (60x Burst) | 1200 | La simultanéité peut être calculée en multipliant le RPS prévu par la latence de chaque requête. Par exemple, un tenant qui a deux Actions post-login associées, prenant chacune 250 ms, avec un RPS total de connexion de 400, aura une simultanéité prévue de (2 \* (400 requests / 1 second) \* (.25 seconds / 1 request)) = 200. Pour éviter que votre tenant soit touché par ces limites de simultanéité, assurez-vous que toute logique d’extensibilité susceptible d’être longue à exécuter, comme les appels à des API externes, prévoit des délais d’attente raisonnables.

Algorithme de limite de débit

Auth0 définit des limites de débit et des limites de rafale pour ses API. Alors que la limite de débit correspond au volume maximal de trafic soutenu que le système autorise à long terme, la limite de rafale correspond au volume maximal de trafic à court terme que le système autorise pendant un intervalle de temps donné. Les limites de débit et les limites de rafale d’Auth0 fonctionnent de concert pour offrir un meilleur contrôle des volumes de trafic variables. Les limites de débit d’Auth0 utilisent un algorithme de seau de jetons comportant les configurations suivantes : * **Clés de limite :** * En général, une clé de limite de débit repose sur deux facteurs principaux : * API et point de terminaison * Type de tenant * Dans certains cas, d’autres facteurs peuvent s’ajouter : * IP source * ID de l’utilisateur cible * **Valeurs de limite :** * **Taille du seau :** Le nombre maximal de requêtes qu’une API ou un point de terminaison peut recevoir au total, ou d’un utilisateur ou d’une adresse IP en particulier, avant l’ajout de nouvelles requêtes. * **Taux de remplissage :** La vitesse à laquelle de nouvelles requêtes sont ajoutées au seau. À partir de ces deux valeurs, Auth0 calcule la limite de rafale et la limite de débit soutenue : * **Limite de rafale :**  Égale à la taille du seau. * **Limite de débit soutenue :** Taux de remplissage en requêtes par minute ou par seconde. Si la limite de débit soutenue est calculée en requêtes par seconde, les nouvelles requêtes sont ajoutées en millisecondes. Si la limite de débit soutenue est calculée en requêtes par minute, les nouvelles requêtes sont ajoutées à chaque seconde.

En savoir plus

* [Politique sur les limites des entités](/docs/fr-ca/troubleshoot/customer-support/operational-policies/entity-limit-policy) * [Cas d’utilisation des limites de débit](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-use-cases)