Postmortem: fallos de autenticación causados por el almacenamiento en caché de JWKS y la rotación de la clave de firma

Fecha: 8 de enero de 2026 (PST)

Duración: aproximadamente 60 minutos

Impacto: algunos tenentes en producción experimentaron fallos en el inicio de sesión y la validación de tokens; el inicio de sesión en la Consola pudo verse afectado

Resumen#

Un desajuste entre una clave de firma rotada y un JWKS en caché en nuestro dominio *.logto.io provocó fallos en la validación de tokens. Borramos la caché de JWKS y revertimos a la clave de firma anterior para restablecer el servicio.

Algunos usuarios aún pueden ver problemas para iniciar sesión en la Consola debido a la caché del navegador. Lamentamos la interrupción causada.

Cronología (PST)#

• 04:00 PM comenzó el incidente (aumentaron los errores de autenticación/validación de tokens)
• 04:35 PM se identificó la causa raíz (JWKS en caché mientras se rotaba la clave de firma)
• 04:41 PM se borró la caché
• 04:49 PM se revirtió la clave de firma
• 05:00 PM el servicio se recuperó; monitoreo continuado

Detalles del incidente#

Impacto#

Durante la ventana del incidente, algunos usuarios no pudieron iniciar sesión y algunas validaciones de tokens fallaron. Esto afectó a múltiples tenentes en producción y también pudo bloquear el acceso a la Consola de Logto.

No hemos visto pruebas de accesos no autorizados relacionados con este incidente; el impacto se limitó a fallos de autenticación.

Acción para clientes#

Si todavía no puedes iniciar sesión en la Consola de Logto, por favor intenta:

• abrir una ventana de incógnito/privada, o
• borrar/deshabilitar la caché de tu navegador, y luego intentarlo de nuevo

Lo que pasó#

1. Actualizamos la configuración de caché de JWKS para los dominios de los tenentes de clientes (*.logto.app). Por error, la caché de JWKS seguía habilitada en nuestro dominio Cloud (*.logto.io).
2. Rotamos la clave de firma de nuestro servicio Cloud. Debido a que las respuestas JWKS para *.logto.io estaban en caché, algunos clientes siguieron usando un JWKS obsoleto y no pudieron validar los nuevos tokens emitidos.
3. Borramos la caché de JWKS para *.logto.io, revertimos a la clave de firma anterior y luego borramos la caché de JWKS de nuevo para asegurarnos de que los clientes recogieran el conjunto de claves revertido.
4. La autenticación se recuperó. Algunos usuarios aún pueden ver problemas de inicio de sesión en la Consola debido a la caché del navegador.

Lecciones aprendidas#

La rotación de claves no es solo una tarea de gestión de claves. Es un cambio de compatibilidad extremo a extremo que debe tener en cuenta el comportamiento de caché entre los emisores y los validadores. Las diferencias de configuración entre dominios (*.logto.app frente a *.logto.io) son un riesgo real. Los cambios que son seguros para un dominio pueden romper otro si no se aplican de forma consistente.

Nuestras pruebas de integración actuales no cubrían el comportamiento de caché JWKS similar al de producción, por lo que este modo de fallo no se presentó antes de la rotación.

Acciones preventivas#

Estamos implementando:

• invalidación de caché JWKS como paso obligatorio en el flujo de rotación de clave de firma (rotar solo después de que la invalidación se complete)
• mantener la caché JWKS deshabilitada hasta que el flujo de invalidación esté listo, y luego volver a habilitar la caché para mejorar el rendimiento
• pruebas de integración similares a producción para la rotación de claves, incluyendo comportamiento de caché de JWKS y verificaciones de invalidación de caché