Fallos de caché JWKS y rotación
Los casos límite detrás de caché JWKS, rotación de claves, valores kid obsoletos y verificadores resistentes a caídas.
JWKS parece simple en un diagrama: el emisor publica claves, los servicios las cachean y los tokens se verifican. Los fallos aparecen en el tiempo. Una clave rota mientras una caché sigue vieja. Un kid nuevo aparece antes de que todas las regiones tengan el JWKS actualizado. Un verificador refresca en cada fallo y ofrece al atacante una pequeña palanca de denegación de servicio. Nada de esto exige romper un algoritmo de firma. Es un sistema distribuido comportándose como tal.
Dos políticas de caché malas
La primera política mala es cachear para siempre. Hace que la rotación normal dé miedo, así que los equipos la evitan hasta que un incidente obliga. La segunda es pedir JWKS en cada request o ante cada kid desconocido. Mantiene las claves frescas, pero mete al emisor en el camino crítico. Un atacante puede enviar miles de tokens con kid aleatorios y provocar una tormenta de fetches si el verificador no limita esos fallos.
Un diseño mejor usa un TTL razonable, sirve desde caché durante fallos breves del emisor y refresca en segundo plano cuando aparece un kid nuevo. Un kid desconocido debería disparar como mucho un refresco por emisor en una ventana corta. Las demás requests deben fallar cerradas con la caché actual, no quedarse esperando una llamada remota.
El orden de rotación importa
Publica la clave pública nueva antes de firmar tokens con la clave privada nueva. Mantén la clave pública antigua hasta que pase la vida máxima del token más el margen de reloj. Si los access tokens viven quince minutos y algunos clientes pueden desviarse cinco, quitar la clave vieja a los diez minutos garantiza falsos rechazos. La línea de tiempo debe incluir propagación CDN, despliegue regional y clientes móviles que guardan tokens sin conexión.
Señales que valen la pena
Mide fallos de verificación por emisor, kid, algoritmo y motivo. Un pico de unknown kid después de un despliegue no es lo mismo que un pico de bad signature. Registra la edad de la caché y el resultado del refresco. En un incidente, esos campos distinguen entre clave comprometida, rollout defectuoso o ruta de red rota hacia JWKS.
Probar los modos de fallo
Un pentest debería incluir comportamiento con JWKS obsoleto, no solo tokens falsificados. ¿La aplicación verifica tokens antiguos durante la rotación? ¿Acepta un token firmado por una clave retirada? ¿Qué ocurre si el endpoint JWKS devuelve 500 o responde lento? Los defensores deben ensayar la rotación con un emisor de staging y estados de caché forzados. Si la primera rotación real ocurre bajo presión, el runbook llega tarde.