Pruebas de carga para picos de inicio de sesión y autenticación

El login es donde la carga duele primero. Un hit a la homepage es un lookup de CDN; un login es un verify de bcrypt, un round-trip a BD, una escritura de sesión, a menudo un baile de OAuth. Cuando un envío de marketing o un cambio de turno a las 9am vuelca decenas de miles de inicios de sesión en el mismo minuto, ese camino es donde el p95 se desploma. Esta plantilla lo scriptea de extremo a extremo desde egress cloud real.

Coste de bcrypt vs throughput

Un solo verify de bcrypt a coste 12 tarda ~250ms en un core x86 moderno. A 1.000 logins/seg eso son 250 cores de CPU de trabajo antes de tocar la base de datos. Coste 10 lo reduce a la mitad; coste 13 lo dobla. Escale el tráfico de password-grant hasta encontrar la rodilla, después dimensione las réplicas de auth contra el factor de coste que realmente despliega — no el del fichero de config de 2019. Objetivo: p95 de login bajo 500ms con el coste real de bcrypt en el bucle.

Intercambio de tokens OAuth2 y rotación de refresh

Los authorization-code grants son dos round-trips: /authorize después /token. Bajo concurrencia, la rotación de refresh-token es donde se rompe la corrección — dos clientes compitiendo por el mismo refresh token, el segundo recibiendo un 401, el SDK desconectando al usuario silenciosamente. Dispare requests de refresh desde varios VUs compartiendo un pool de tokens para sacar a la luz esa race condition. Rastree /token p99 bajo 1s y vigile clusters de 4xx que solo aparecen por encima de ~500 RPS.

Claves calientes en el session store

Respalde las sesiones con Redis y la escritura de login se concentra en pocas claves: contadores de rate-limit por IP, contadores de lockout por usuario, la clave de session-list por usuario. La contención de hot-key clava la CPU de un shard mientras el resto está ocioso. Ejecute contra el cluster, vigile redis-cli --hotkeys junto con el test — el p95 de GET/SET de sesión debe quedarse bajo 5ms. Si sube, su sharding key está mal, no su número de VUs.

El lockout de cuenta se convierte en DoS

El lockout-tras-N-intentos-fallidos, bajo carga, es una primitiva de amplificación: un atacante con una lista de usuarios bloquea cada cuenta con un solo intento fallido en cada una. Incluya un escenario controlado de credenciales fallidas para medir cómo el estado de lockout se propaga por su backend de lock distribuido, y confirme que los usuarios legítimos siguen pasando mientras se descarta el tráfico malo. Los rate limits por-IP, por-cuenta y por-tenant se afinan cada uno por separado.

Password spray e IPs de egress compartidas

VUs repartidos en un puñado de IPs de egress se parecen exactamente a password spray para su WAF. Si el test dispara el rate-limiter en el primer escalón de ramp, está testeando su WAF, no su servicio de auth. Reparta los VUs por 26+ regiones cloud para que el presupuesto por-IP sea realista. Los umbrales de inyección de captcha pertenecen al script — si los usuarios reales encuentran captcha a los 5 intentos fallidos, su script debe encontrarlo en el mismo punto.

Verify de JWT y SLO de SAML

Después del login, cada request verifica un JWT. RS256 es ~10x la CPU de HS256 y aparece en estado estable, no en el pico. Los endpoints de single-logout de SAML encolan bajo logouts concurrentes iniciados por el IdP y casi nunca se benchmarkean. Cubra ambos: una fase warm post-login que ejercite el verify de JWT, más una tormenta SLO para SAML.

Ejecútelo

Importe el escenario, apunte a staging, escale de 100 al pico de logins concurrentes en 10 minutos. Use modo JMeter con un flujo grabado, o modo k6 para scriptear el handshake OAuth directamente. Conéctelo al CI para que cada deploy del servicio de auth ejecute el pico antes de promocionar.