Casos de uso del límite de tasa

Cómo determinar si se está aplicando un límite de tasa

​

Descubra cuándo se aplica el límite de tasa a las solicitudes a un inquilino

Hay varias formas de determinar si Auth0 está aplicando un límite de tasa a un producto del cliente. A continuación, se indican las posibles causas del límite de tasa.

​

Registros del Tenant

Al suscribirse a distintos registros del inquilino, puede hacer un seguimiento de los problemas relacionados con el volumen de solicitudes. Para entender cómo funcionan los registros de eventos del inquilino y de operaciones en Auth0, consulte Registros.

​

api_limit

El evento api_limit se activa inmediatamente después de que se supere el límite de tasa del bucket global de límite de tasa para Authentication o Management API. Si el número de tokens de solicitud utilizados se mantiene por encima del 80 % tras un minuto para el mismo bucket de límite de tasa, se genera un segundo registro de advertencia. Si se supera el límite de tasa de un bucket diferente, se genera un nuevo evento api_limit. Esto ayuda a los clientes a identificar qué configuración de límite de tasa están activando sus llamadas a la API, lo que constituye un primer paso fundamental para diagnosticar la causa raíz.

​

api_limit_warning

El registro api_limit_warning se activa cuando la tasa de solicitudes de un cliente consume el 80 % de los tokens de solicitud de un bucket de límite de tasa determinado. Si la cantidad de tokens de solicitud utilizados se mantiene por encima del 80 % después de un minuto en el mismo bucket de límite de tasa, se genera un segundo registro de advertencia. Si se supera el umbral del 80 % en un bucket de límite de tasa diferente, se crea un nuevo registro api_limit_warning.

​

appi (Solo para Public Performance Burst)

El registro appi se activa cuando un inquilino del cliente con el complemento Public Performance Burst supera su límite de tasa sostenido de 100 RPS para solicitudes a la Authentication API, lo que consume un bloque de un minuto de su asignación de ráfaga de 48 horas. Si, después de 15 minutos, la tasa de solicitudes vuelve a superar el límite sostenido de 100 RPS, se activa un segundo registro appi.

​

Respuestas de la API

Las respuestas de la API de Auth0 devuelven respuestas HTTP 429 (Too Many Requests) con el límite de tasa superado. Esto permite a los clientes observar en tiempo real la aplicación del límite de tasa. Sin embargo, esto solo resulta útil para aplicaciones personalizadas de clientes que interactúan directamente con la API de Auth0.

​

Gestión de errores del SDK

Si utiliza un SDK, consulte las páginas de errores de las bibliotecas SDK de Management API.

​

Páginas de error

La respuesta de la página de error se envía para los endpoints que muestran contenido HTML al usuario final. Si su inquilino está configurado para usar páginas genéricas (alojadas por Auth0), Auth0 muestra la página de error en lugar del contenido esperado cuando se supera el límite de respuesta.  Si su inquilino está configurado para usar páginas de error personalizadas, se redirige al usuario a la URL de la página de error personalizada con el error correspondiente en el parámetro de consulta error_description.  Para obtener más información, consulte Endpoints afectados y la descripción de Error JSON.

​

Averigüe por qué se está aplicando un límite de tasa a un inquilino

Si cree que las solicitudes del inquilino están alcanzando el límite de tasa y necesita ayuda para entender por qué, abra una solicitud a través del Centro de soporte.  Como parte de la solicitud, incluya el registro sin procesar completo en el que se observó el problema.

​

Predecir cuándo se aplicará el límite de tasa a las solicitudes de un inquilino

Auth0 informa del estado actual de sus límites de tasa mediante encabezados de respuesta HTTP en los endpoints que tienen configuradas políticas de límite de tasa. Este estado se comunica de la siguiente manera:

• x-ratelimit-limit: Número máximo de solicitudes disponibles.
• x-ratelimit-remaining: Número de solicitudes restantes hasta que el bucket se vuelva a llenar con solicitudes adicionales.
• x-ratelimit-reset: Marca de tiempo UNIX, en segundos, del momento previsto en que se agregarán solicitudes adicionales al bucket.

Por ejemplo:

Una API tiene el siguiente límite de tasa:

• Límite de ráfaga: 1000
• Límite de tasa sostenido: 100 solicitudes por segundo (en una ventana fija)

A partir de esta información, puede deducir lo siguiente:

• El límite de tasa sostenido es de 100 solicitudes por segundo en una ventana fija.
• Debido a la ventana fija, el bucket de solicitudes se vuelve a llenar cada segundo.

Si recibe los siguientes encabezados x- en la respuesta de su API:

• x-ratelimit-limit: 1000
• x-ratelimit-remaining: 50
• x-ratelimit-reset: 1675452600

Ahora sabe que:

• Su inquilino ha consumido 950 de las 1000 solicitudes permitidas para esa API y que solo le quedan 50 solicitudes hasta que se agreguen más.
• Se agregarán nuevas solicitudes en 1675452600, es decir, a las 7:30:00 PM UTC del 3 de febrero de 2023.
• En ese momento se agregará 1 nueva solicitud

Por lo tanto, si está realizando solicitudes a una tasa superior a la descrita anteriormente, es de esperar que se aplique un límite de tasa. El tiempo que tardará en aplicarse el límite de tasa depende del límite de ráfaga y de cuánto esté superando el límite sostenido.

​

Ejemplos de cómo se aplican los límites de tasa

​

Ejemplo de solicitudes por segundo

Suponga que Auth0 lanza una nueva API llamada /ratelimitexample con los siguientes valores de límite de tasa:

• Límite de ráfaga: cinco (5) solicitudes
• Límite de tasa sostenida: 10 solicitudes por segundo.

Puntos clave:

• La API comienza con cinco tokens de solicitud y nunca superará esa cantidad, que equivale al límite de ráfaga.
• El bucket de 10 tokens se repone cada segundo mediante una «ventana fija». Se agregan tokens nuevos al bucket y se vuelve a llenar al «inicio» de cada segundo.

 Escenario de ejemplo con límites de tasa:

En este escenario:

• T0 - T1sec:  El usuario final realiza seis solicitudes en el primer segundo. Cinco solicitudes —equivalentes al límite de ráfaga— reciben una respuesta 200. La sexta solicitud recibe un error 429 porque no quedan tokens de solicitud en el bucket.
• T1sec - T2sec:  Auth0 vuelve a llenar por completo el bucket de tokens de solicitud debido al algoritmo de ventana fija. Como resultado, las solicitudes séptima a undécima se procesan correctamente, y el bucket se agota con la duodécima solicitud, lo que da lugar a un error 429.
• T2sec - T3sec:  Auth0 vuelve a llenar el bucket de tokens una vez más, y la siguiente solicitud (13) recibe una respuesta 200.

​

Ejemplo de solicitudes por minuto

Supongamos que Auth0 lanza una nueva API llamada /ratelimitexample2 con los siguientes valores de límite de tasa:

• Límite de ráfaga:  Cinco (5) solicitudes
• Límite de tasa sostenida:  Seis (6) solicitudes por minuto.

Puntos clave:

• La API comienza con cinco tokens de solicitud, lo que equivale al límite de ráfaga.
• El bucket de seis tokens se rellena cada minuto mediante una “ventana fija”. Se agregan nuevos tokens al bucket y se vuelve a llenar al inicio de cada minuto.

Escenario de ejemplo con límites de tasa:

En este escenario:

• T0 - T+1min:  El usuario final realiza seis solicitudes en el primer minuto. Cinco solicitudes —equivalentes al límite de ráfaga— reciben una respuesta 200. La sexta solicitud recibe un error 429 porque no quedan tokens de solicitud.
• T+1min - T+2min:  Auth0 rellena el bucket de tokens debido al algoritmo de ventana fija. Como resultado, las solicitudes séptima a undécima se completan correctamente, y el bucket se agota con la duodécima solicitud, lo que da como resultado un error 429.
• T+2min: Auth0 rellena el bucket de tokens una vez más, y la siguiente solicitud (13) recibe una respuesta 200.

​

Otros escenarios

En ocasiones, Auth0 puede asignar dos límites de tasa a una misma API.  Esto se hace para configurar un límite de ráfaga y un límite de tasa sostenido más ajustado a las necesidades del servicio.  En la práctica, el primer límite de tasa pasa a ser el límite de ráfaga efectivo, y el segundo límite de tasa pasa a ser el límite de tasa sostenido efectivo.  En este escenario, Auth0 solo publica los límites efectivos de ráfaga y de tasa sostenida, en lugar de comunicar los límites reales de ráfaga y de tasa sostenida.

​

Uso de la API para el inicio de sesión y el registro de usuarios finales

Existen varios flujos de autenticación, entre ellos Inicio de sesión, Registro y Cambio de contraseña. Los más habituales suelen ser Inicio de sesión, seguido de Registro.

Cuando un usuario final inicia sesión, se realizan varias llamadas a endpoints de Authentication API para determinar si está autorizado a recibir un token de autorización y, por lo tanto, acceder a la aplicación solicitada.

La cantidad exacta de llamadas a la API depende de varias configuraciones:

• Experiencia de autenticación (por ejemplo, nuevo Universal Login o Classic Login)
• Flujo de autenticación (por ejemplo, Inicio de sesión, Registro o Cambio de contraseña)
• Tipo de flujo de autenticación (por ejemplo, Inicio de sesión mediante username / contraseña; Inicio de sesión mediante inicio de sesión social; Inicio de sesión cuando ya existe un token de autenticación)

A continuación, describimos algunas configuraciones habituales de los clientes y su impacto en el uso de la API.

​

Universal Login

Auth0 Universal Login proporciona una función esencial de un servidor de autorización: el flujo de inicio de sesión. Cuando un usuario necesita demostrar su identidad para obtener acceso a tu aplicación, puedes redirigirlo a Universal Login y dejar que Auth0 gestione el proceso de autenticación.

Flujo de autenticación	Tipo de flujo	Solicitudes a los endpoints de Authentication API
Inicio de sesión	Desafío de username/contraseña*	5
Inicio de sesión	Proveedor de identidad de terceros – p. ej., inicio de sesión social o empresarial	6
Inicio de sesión	Existe una sesión de autenticación de Auth0	1
Registro	mediante username/contraseña	6

​

Modificadores

Determinadas configuraciones de autenticación modifican el número base de solicitudes. Estos ajustes dependen de medidas de seguridad adicionales o de flujos de autenticación:

Modificador	Descripción	Solicitudes adicionales
ID First	Identifica al usuario antes de solicitar las credenciales.	+2
MFA	Añade autenticación multifactor.	+2 por factor
OTP	Código de un solo uso para la autenticación	+2
Inicio de sesión empresarial	Autenticación mediante una conexión empresarial (por ejemplo, SAML, OIDC, LDAP).	+1
Credenciales de cliente	Se usa para la autenticación de máquina a máquina. Se aplica en todos los casos, incluso si se usan Actions.	+1

*Cualquier opción usada en combinación se suma al total de solicitudes.

​

Classic Login

Classic Login es una experiencia de inicio de sesión alojada en Auth0 que utiliza JavaScript para su personalización. Implementar Classic Login es menos complejo que incrustar el proceso de autenticación directamente en tu aplicación y puede ayudar a evitar los riesgos de la autenticación entre dominios.

Flujo de autenticación	Tipo de flujo	Solicitudes
Inicio de sesión	Desafío de username/contraseña	8
Inicio de sesión	Proveedor de identidad de terceros: p. ej., inicio de sesión social o empresarial	8
Inicio de sesión	Existe una sesión de autenticación de Auth0	2
Registro	Username/contraseña	8

Los clientes que configuren bases de datos personalizadas deben agregar dos (2) llamadas adicionales a la Authentication API a cada flujo de autenticación descrito anteriormente. Para obtener más información, consulta Conexiones de base de datos personalizadas.

​

Modificadores

Los siguientes factores aumentan la cantidad de solicitudes para Classic Login:

Modificador	Descripción	Solicitudes adicionales
Solo autenticación por SMS	Cuando se utiliza SMS como método principal de autenticación.	+7
Inicio de sesión social nativo	Inicio de sesión mediante un proveedor social nativo (p. ej., Google, Facebook).	+1
Redirecciones	Las redirecciones adicionales durante la autenticación aumentan la cantidad de solicitudes.	+1