> ## Documentation Index
> Fetch the complete documentation index at: https://docs-staging-feat-init-gt-translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Comment déterminer si vous êtes soumis à une limitation du débit
# Cas d’utilisation de la limitation du débit
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](/docs/fr-ca/deploy-monitor/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’Management API. 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éé.
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)](http://tools.ietf.org/html/rfc6585#section-4) 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](/docs/fr-ca/libraries#mgmt).
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](/docs/fr-ca/customize/login-pages/custom-error-pages), 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](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy/authentication-api-endpoint-rate-limits#affected-endpoints) et les descriptions de [JSON Error](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy/authentication-api-endpoint-rate-limits#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](http://support.auth0.com). 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](https://en.wikipedia.org/wiki/Unix_time), 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 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 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](/docs/fr-ca/authenticate/login/auth0-universal-login) fournit la fonctionnalité essentielle d’un serveur d’autorisation : 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.
| Flux d’authentification | Type de flux | Requêtes aux points de terminaison de l’Authentication API |
| ----------------------- | ----------------------------------------------------------- | ---------------------------------------------------------- |
| Connexion | Vérification par nom d’utilisateur/mot de passe\* | 5 |
| Connexion | Fournisseur d’identité tiers – p. ex., Social ou Work Login | 6 |
| Connexion | Une session d’authentification Auth0 existe | 1 |
| Inscription | par 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. | +2 |
| **MFA** | Ajoute l’authentification multifacteur. | +2 par facteur |
| **OTP** | Mot de passe à usage unique pour l’authentification | +2 |
| **Enterprise Login** | Authentification via 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.
Classic Login
[Classic Login](/docs/fr-ca/authenticate/login/auth0-universal-login/universal-login-vs-classic-login/classic-experience) 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.
| Flux d’authentification | Type de flux | Requêtes |
| ----------------------- | ----------------------------------------------------------- | -------- |
| Connexion | Vérification par nom d’utilisateur et mot de passe | 8 |
| Connexion | Fournisseur d’identité tiers – p. ex., Social ou Work Login | 8 |
| Connexion | Une session d’authentification Auth0 existe | 2 |
| Inscription | Nom d’utilisateur et mot de passe | 8 |
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](/docs/fr-ca/authenticate/database-connections/custom-db).
Modificateurs
Les facteurs suivants augmentent le nombre de requêtes pour Classic Login :
| Modificateur | Description | Requêtes supplémentaires |
| --------------------------------------- | --------------------------------------------------------------------------------------------- | ------------------------ |
| **Authentification par SMS uniquement** | Lorsque le SMS est utilisé comme principale méthode d’authentification. | +7 |
| **Native Social Login** | Connexion au moyen 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 |