Sesiones JWT resistentes al replay
Notas de diseño para limitar replay cuando se filtran bearer tokens: jti, estado de sesión, señales de dispositivo y rotación.
Los JWT bearer son simples porque poseer el token basta. Ese es también el problema. Si un atacante obtiene el token desde logs, malware, un proxy, una extensión de navegador o un ticket de soporte pegado por error, la API normalmente no distingue entre atacante y usuario. La resistencia al replay busca reducir esa brecha sin fingir que un JWT se volvió una credencial ligada a hardware.
Empieza por las rutas de fuga
Antes de añadir mecanismos, mapea por dónde viajan los tokens. Los encabezados Authorization pasan por balanceadores, logs de aplicación, agentes APM, reportes de error, proxies inversos y a veces integraciones controladas por clientes. Los tokens de navegador pueden aparecer en herramientas de session replay o comandos curl copiados. Los tokens móviles pueden llegar a crash reports. Todo diseño anti-replay falla si la organización sigue duplicando bearer tokens en lugares legibles por atacantes.
Las vidas cortas ayudan, pero solo después de reducir fugas. Un token de cinco minutos en logs verbosos sigue siendo acceso remoto a la API durante cinco minutos si concede permisos amplios. Scope y audiencia importan tanto como duración.
jti y estado de sesión servidor
Añadir jti da un identificador a cada token. Se vuelve útil cuando el verificador puede revisar ese identificador contra estado de sesión, lista de revocación o cadena de rotación. Sin lookup, jti es solo una etiqueta. Con lookup, recuperas algo de semántica de sesión: revocar un dispositivo, detectar reutilización después de rotación de refresh e invalidar tokens tras un reset de credenciales.
Detectar patrones de replay
No bloquees solo porque cambie la IP. Redes móviles y VPN corporativas lo vuelven ruidoso. Combina señales: viaje imposible, cambio de familia de user agent, cambio de dispositivo, reutilización de un refresh token antiguo y acceso desde una región nunca vista en la cuenta. Registra lo suficiente para investigar, pero no tokens completos. Hashea jti o ids de sesión si los logs salen del perímetro de confianza.
Opciones más fuertes
Los enfoques de proof of possession atan el token a una clave que el cliente debe usar en cada request. DPoP y mTLS son ejemplos, pero añaden coste operativo. Tienen sentido para APIs de alto valor, clientes máquina, integraciones de socios y superficies administrativas. Para sesiones web normales, rotación de refresh bien gestionada, cookies HttpOnly, scopes estrechos y revocación rápida pueden ser mejor equilibrio.
Diseño práctico
Trata la resistencia al replay como capas. Reduce exposición de tokens, usa access tokens cortos, rota refresh tokens, guarda estado de sesión en servidor y alerta sobre señales de reutilización. El JWT puede seguir siendo la credencial de request mientras el modelo de sesión vive fuera. Esa separación marca la diferencia entre "robado una vez, válido en todas partes" y "robado una vez, contenido rápido".