Expiración JWT y desfase de reloj en producción

Los bugs de expiración en JWT rara vez nacen de no entender exp. Casi todos saben que es un timestamp Unix y que los tokens expirados deben fallar. El problema empieza en los bordes: colas de reintento, móviles con relojes incorrectos, workers CDN en distintas regiones y servicios que no comparten la misma tolerancia de reloj. Cinco minutos de margen pueden ser una mejora de fiabilidad o una extensión silenciosa para cada token robado.

Los claims son simples, el sistema no

exp indica cuándo el token deja de ser válido. nbf indica cuándo empieza. iat indica cuándo fue emitido, aunque muchos verificadores lo tratan como informativo si no añades política. En un único proceso con NTP sano, parece fácil. En una pila distribuida, el token puede emitirse en una región, verificarse en otra, reintentarse tras un timeout y terminar en una cola de workers segundos después.

El atacante mira la ventana de tolerancia. Si los access tokens duran diez minutos y el verificador acepta cinco minutos de desfase, la vida útil tras un robo se acerca a quince minutos. Si el endpoint de refresh usa una tolerancia distinta a las APIs, un token robado puede fallar en una ruta y todavía renovarse en otra.

Elegir una ventana de tolerancia

Usa el menor margen que encaje con el comportamiento medido de tus relojes, no un valor copiado. Treinta a sesenta segundos bastan para muchos sistemas server side con sincronización sana. Los clientes móviles o desktop pueden desviarse varios minutos, pero el servidor debe seguir siendo la autoridad. Si el reloj del cliente es malo, corrige la experiencia de refresh y reintento en lugar de regalar una gracia amplia a todos los tokens.

Casos límite para probar

Prueba tokens expirados hace un segundo, justo dentro del margen y justo fuera. Prueba nbf en el futuro cercano. Prueba iat muy en el futuro, porque algunos sistemas aceptan por accidente tokens emitidos mañana. También prueba jobs en segundo plano. Si una request encola trabajo usando un token que expira antes de que el worker corra, el worker debería usar una decisión derivada o credenciales de servicio, no volver a confiar en un token de usuario viejo.

Logs e incidentes

Registra el reloj del verificador, timestamp del claim, margen aplicado y motivo del fallo. Sin esos campos, los incidentes de expiración son adivinanzas. No registres tokens completos. Ante sospecha de robo, reducir el margen puede contener daño, pero solo si sabes qué servicios lo aplican de forma consistente.

Política sensata

Access tokens cortos, tolerancia estrecha, refresh explícito y código de verificación común ganan a las excepciones ingeniosas. Documenta la interpretación exacta de exp, nbf e iat por emisor. La política debe ser tan clara que una persona de guardia pueda predecir el resultado con tres timestamps y un nombre de servicio.