Test de Carga API JWT: Manejo de Tokens

Prueba de carga de una API protegida con tokens JWT

La mayoría de las pruebas de carga de API fallan en la puerta: 401 en cada petición porque el token nunca se envió, o un endpoint de login machacado por la propia prueba. Esta plantilla lo hace como el tráfico de producción: obtener un token una vez, enviarlo en la cabecera Authorization: Bearer en cada petición medida y dejar el flujo del token fuera de las cifras que evalúas.

Configuración

Ejecutar esta plantillaAbre el formulario de prueba cloud con estos valores rellenados. El plan gratuito la ejecuta con el límite de usuarios gratuito; inicia sesión o crea una cuenta gratuita antes.

El botón rellena usuarios, duración y rampa en el formulario de prueba cloud. Añade tus endpoints y la cabecera Authorization (emite un token de prueba con una vida más larga que la ejecución) y arranca la prueba.

Meter el token y dejarlo fuera de las métricas

• Token de prueba de larga duración. Emite un token para el usuario de prueba con caducidad posterior a la ejecución (una hora sobra) y pégalo en la cabecera. Es lo más sencillo y mide la API, no el proveedor de identidad.
• Login una vez por usuario virtual. Cuando los tokens son de corta duración, obtén el token en un paso de preparación y reutilízalo; en la versión k6 de abajo es la función setup(), que se ejecuta una vez y entrega el token a cada usuario virtual.
• Tokens caducados o revocados a propósito. Una segunda ejecución pequeña con un token inválido te dice lo que cuesta un 401 bajo carga. Rechazar una petición debería ser más barato que servirla; si el p95 de los 401 se acerca al p95 de los 200, la validación del token está tocando la base de datos.

Qué leer en los resultados

• 401 y 403 por endpoint. Cualquiera de ellos en la ejecución principal significa que el token no llegó a una petición o caducó a mitad. Arregla la preparación, no lo diluyas en la media.
• p95 por endpoint. Las lecturas deberían quedar muy por debajo de la escritura; si GET /me es tan lento como POST, el coste está en la validación del token o en una comprobación de permisos por petición.
• 429. Un limitador de tasa por token o por usuario saltará cuando 200 usuarios virtuales compartan una identidad. Es un hallazgo real sobre el limitador, no sobre la capacidad, y el motivo para dar a cada usuario virtual su propio token en la segunda iteración de esta prueba.

Umbrales de aprobado/suspenso para esta plantilla

El mismo escenario como script k6

Súbelo a una prueba k6 en la nube cuando necesites obtener el token en tiempo de ejecución. Las credenciales van en variables de entorno, nunca en el script.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '1m', target: 200 },
    { duration: '4m', target: 200 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<300'],
    http_req_failed: ['rate<0.005'],
  },
};

const BASE = 'https://api.example.com';

// Runs once; the returned token is shared by every virtual user.
export function setup() {
  const res = http.post(`${BASE}/auth/login`, JSON.stringify({
    username: __ENV.LF_USER,
    password: __ENV.LF_PASS,
  }), { headers: { 'Content-Type': 'application/json' } });
  check(res, { 'login ok': (r) => r.status === 200 });
  return { token: res.json('access_token') };
}

export default function (data) {
  const params = { headers: { Authorization: `Bearer ${data.token}` } };
  const me = http.get(`${BASE}/me`, params);
  check(me, { 'me 200': (r) => r.status === 200 });
  const orders = http.get(`${BASE}/orders?limit=20`, params);
  check(orders, { 'orders 200': (r) => r.status === 200 });
  sleep(0.5 + Math.random() * 0.5);
}

FAQ sobre pruebas de carga de APIs protegidas con JWT

¿Dónde pongo el token en una prueba cloud de LoadFocus?

En las cabeceras de cada petición: nombre Authorization, valor Bearer seguido del token. Guárdalo como preset de cabeceras y estará disponible en todas las pruebas del equipo.

¿Debe el endpoint de login formar parte de la prueba de carga?

No en la misma ejecución. Hacer login 200 veces por segundo prueba tu proveedor de identidad y distorsiona todas las demás cifras. Prueba el endpoint de login aparte con una configuración pequeña.

La prueba devuelve 401 en todas las peticiones. ¿Qué falla?

O falta la cabecera en algunas peticiones, o el token caducó durante la ejecución (emite uno con más vida), o la API espera el token en otro sitio (una cookie o una cabecera X-Api-Key). Revisa el cuerpo de respuesta de una petición fallida en la pestaña Errors.

¿Funciona con OAuth 2.0 client credentials?

Sí. El flujo es el mismo: pedir un token al endpoint de tokens una vez y enviarlo como cabecera bearer. La versión k6 de arriba cambia el POST de login por la llamada al endpoint de tokens.