Análisis post-mortem: cambio inesperado de `iss` en JWT

Resumen#

El 2024-03-18, una actualización que cambió el comportamiento del emisor de JWT en Logto Cloud interrumpió los flujos de autenticación para usuarios con dominios personalizados y validación de iss. La solución requirió que estos usuarios actualizaran su lógica de validación.

• Usuarios afectados: usuarios con dominios personalizados habilitados y que realizan validación de iss.
• Gravedad: Crítica, rompiendo la validación de iss dentro de los flujos de autenticación.

Causa raíz#

La actualización cambió el campo iss para que coincidiera con el dominio solicitado, rompiendo las validaciones existentes que esperaban el emisor predeterminado anterior.

Cronología#

• 2024-03-18 10:00 (UTC): se implementaron actualizaciones, cambiando el comportamiento de iss.
• 2024-03-18 23:30 (UTC): se recibió el primer informe de usuario sobre la ruptura del comportamiento existente.
• 2024-03-19 12:00 (UTC): se confirmó el problema y se comenzó a investigar.
• 2024-03-19 14:00 (UTC): se identificó la causa raíz y el impacto.
• 2024-03-20 20:00 (UTC): se preparó el correo electrónico para los usuarios afectados.
• 2024-03-20 06:00 (UTC): se enviaron correos electrónicos a todos los usuarios afectados.

Análisis del impacto#

Detalles de la liberación#

Logto Cloud soporta dominios personalizados para autenticación. Los desarrolladores que tienen inquilinos con dominio personalizado habilitado pueden establecer el endpoint en el dominio personalizado en los SDKs, luego el usuario final usará este endpoint para iniciar el proceso de autenticación y obtener tokens. Algunos tokens están en forma de JWT, que incluye un campo iss que indica el emisor de este token. Anteriormente, incluso cuando se usaba un endpoint de dominio personalizado para solicitar un token de acceso, el emisor seguía siendo nuestro dominio estándar por defecto ([tenant-id].logto.app).

Pero el dominio del emisor debería ser el mismo que el endpoint solicitado. Así que lanzamos una actualización para solucionar este problema, y ahora el campo iss reflejará automáticamente el dominio utilizado en la solicitud.

Para aquellos que ya están usando dominio personalizado para otorgar tokens e implementaron validación de campo iss en el servidor de recursos, esto podría ser un cambio disruptivo. La verificación de autenticación existente fallará debido al cambio de emisor. Para solucionar esto, los desarrolladores necesitan cambiar el código de validación, reemplazar el emisor esperado por el nuevo con dominio personalizado.

No logramos considerar completamente el impacto en las validaciones existentes de iss, como resultado, este lanzamiento se convirtió en un cambio disruptivo sin notificación previa.

Resolución#

Notificamos a los usuarios afectados por correo electrónico, aconsejándoles actualizar su validación de iss para que coincida con el dominio solicitado.

¿Reversiones?#

El cambio es una corrección necesaria para el campo del emisor, y algunos usuarios pueden haber adaptado ya el nuevo comportamiento. Una reversión causaría confusión e inconsistencia.

Lecciones aprendidas#

• Los cambios de código que afectan la autenticación central deben tener la aprobación del equipo además de las revisiones regulares.
• Las pruebas automáticas deben cubrir más casos, especialmente en escenarios específicos de la nube.

Medidas correctivas y preventivas#

• Añadir pruebas de integración: Añadir casos de prueba para cubrir el escenario en este incidente.
• Proyectos de monitoreo de características: Además de Logto Cloud, crear nuestros propios proyectos laterales e integrarlos profundamente con Logto para detectar problemas potenciales antes de los lanzamientos.