Logto v1.42.0 trae archivos de verificación de dominio personalizado, listas blancas de correos electrónicos con patrones comodín, enlaces mágicos para restablecer contraseñas, un webhook Grant.LimitExceeded y una renovación del protocolo con node-oidc-provider v9, Koa 3 y protección SSRF activada por defecto.
SimengDeveloper
Deja de perder semanas en la autenticación de usuarios
Lanza aplicaciones seguras más rápido con Logto. Integra la autenticación de usuarios en minutos y concéntrate en tu producto principal.
Logto v1.42.0 es una versión orientada a dominios y protocolos. Ofrece a los equipos una manera de probar la propiedad del dominio sin tener que montar otro host, un control más fino sobre qué correos pueden ingresar a un tenant y una ruta de restablecimiento de contraseña más fluida para los usuarios finales. Bajo el capó, Logto se actualiza a node-oidc-provider v9 y Koa 3, y activa la protección SSRF para solicitudes OIDC salientes por defecto. Aquí tienes las novedades.
Archivos de verificación de dominio personalizado#
Los servicios de terceros a menudo verifican la propiedad de un dominio pidiéndote que sirvas un pequeño archivo en una ruta fija. Hasta ahora eso significaba ejecutar un host separado junto a tu dominio personalizado de Logto.
Ahora puedes adjuntar archivos de verificación a un dominio personalizado activo desde Consola > Configuración del tenant > Dominios. Cada archivo tiene:
Una ruta que es o bien un nombre de archivo a nivel raíz con una extensión (por ejemplo /verify.txt) o una ruta bajo /.well-known/.
Un tipo de contenido text/plain o application/json. El contenido JSON se valida al guardar.
Un contenido de hasta 16 KB.
Se pueden configurar hasta 10 archivos por dominio y las rutas deben ser únicas. Logto sirve coincidencias exactas en GET y HEAD con el tipo de contenido configurado y refuerzo de la respuesta. Las rutas existentes de Logto siempre tienen prioridad sobre un archivo de verificación en la misma ruta, por lo que un archivo mal configurado nunca puede ocultar un endpoint real. La experiencia en la Consola está localizada en todos los idiomas compatibles.
Como Logto no interfiere en el contenido de los archivos, esto funciona para cualquier tipo de verificación de proveedor sin que Logto tenga que modelar un comportamiento específico del proveedor.
Reglas de acceso al correo: lista blanca y patrones comodín#
La política de lista negra de correos electrónicos se expande a un conjunto más completo de reglas de acceso al correo, configurables en Consola > Seguridad > Lista negra de correos.
Lista blanca personalizada de correos electrónicos. Configura una lista blanca de direcciones de correo, dominios o patrones comodín. Cuando se establece la lista blanca, solo se aceptan correos que coinciden para nuevos registros y nuevos correos vinculados — tanto en el registro por correo como en las actualizaciones del correo de la cuenta.
Patrones comodín. Tanto la lista blanca como la lista negra aceptan patrones comodín de direcciones y dominios, tales como foo*@example.com, *@example.com y @*.example.com, junto a direcciones exactas ([email protected]) y dominios (@example.com).
Advertencias de conflicto. La Consola avisa cuando una entrada en la lista blanca también coincide con una regla de bloqueo, cuando una entrada usa un signo más mientras el subdireccionamiento de correo está bloqueado, y cuando las reglas combinadas no permitirían la entrada de ningún nuevo correo.
La lógica de coincidencia y validación se comparte mediante ayudantes reutilizables en @logto/core-kit, así que las mismas reglas se aplican en todos los puntos por donde un correo entra a un tenant.
La aplicación Experience ahora soporta los flujos de restablecimiento de contraseña que verifican enlaces mágicos con token de un solo uso directamente desde la página de destino de restablecimiento de contraseña, además de los códigos de verificación.
Cuando se eliminan permisos OIDC porque una aplicación excedió su límite máximo, Logto ahora dispara un evento webhook Grant.LimitExceeded, seleccionable en la configuración de webhooks de la Consola como cualquier otro evento.
El payload informa userId, applicationId, revokedGrantIds, maxAllowedGrants y preRevocationActiveGrantCount. El envío es fire-and-forget: los fallos se registran como entradas de auditoría TriggerHook.Grant.LimitExceeded y nunca bloquean la respuesta de autenticación.
Proveedor OIDC actualizado a node-oidc-provider v9#
El mayor cambio aquí es una corrección de seguridad en la revocación de tokens.
Revocar un token de acceso opaco ahora también revoca cualquier token dentro del mismo permiso, incluyendo el token de renovación (refresh token). En la v8, el token de renovación seguía siendo utilizable tras la revocación y podía seguir solicitando nuevos tokens de acceso.
Otras actualizaciones del protocolo en v9:
El endpoint de revocación ahora rechaza tokens de acceso JWT con unsupported_token_type, en vez de devolver una respuesta exitosa sin revocar nada como en v8.
El endpoint de metadatos del servidor de autorización RFC 8414 está disponible en /oidc/.well-known/oauth-authorization-server.
La declaración redundante at_hash se elimina de los ID tokens emitidos en el endpoint de token.
Los ID tokens ya no incluyen el header opcional typ: "JWT". OpenID Connect define los ID tokens como JWTs y no requiere que los clientes verifiquen este header.
Acción requerida para verificación personalizada de ID token. No es necesario hacer nada al usar un SDK oficial de Logto. Si tu integración realiza verificación personalizada de ID token, actualízala para permitir que la declaración at_hash pueda estar ausente y que el header typ: "JWT" también pueda faltar.
Logto ahora funciona sobre Koa 3, la línea de lanzamiento mantenida activamente que recibe las correcciones de seguridad de Koa primero. No se espera cambio de comportamiento: todos los endpoints, flujos OIDC y respuestas API funcionan exactamente igual que antes.
Los secretos internos de aplicaciones ya no se exponen mediante las APIs de gestión.
La política de lista negra de correos ya no se devuelve en las respuestas públicas de la experiencia de inicio de sesión.
Recuperar tokens de acceso de proveedores externos mediante la Account API ahora requiere el scope de usuario identities, igualando el resto de endpoints de identidad SSO social y empresarial.
Los códigos de verificación de la Account API ya no se envían a direcciones de correo bloqueadas.
La validación de correo y dominios ahora coincide con valores completos y aplica etiquetas de dominio más estrictas.
Correcciones en experiencia, almacenamiento y estabilidad#
Cuando un flujo de registro social o SSO es rechazado por las reglas de acceso al correo, al reconocer el error ahora se devuelve al usuario a la página de inicio de sesión de Logto en vez de devolverlo al proveedor de identidad externo.
MFA se activa automáticamente tras que un usuario vincule un factor a través de las Account APIs.
Crear un nuevo conector de correo o SMS ejecuta la inserción y la limpieza de conectores antiguos en una sola transacción de base de datos. Antes, una caída entre ambas sentencias podía dejar conectores duplicados.
Las credenciales del clúster Redis ahora se decodifican por porcentaje, por lo que las conexiones funcionan si el usuario o contraseña contiene caracteres reservados para URL.
TLS se habilita correctamente ahora para las conexiones de clúster Redis que utilizan el protocolo rediss.
jose v6: Los conectores Apple, Google, OAuth y OIDC ahora usan jose 6, que funciona sobre la Web Crypto API en lugar del módulo crypto de Node. La firma y verificación de ID tokens funciona exactamente igual que antes.
GitLab: Se eliminó la dependencia jose no utilizada, así que instalar el conector ya no descarga un paquete que nunca se importaba.
Aliyun SMS: Los números de teléfono de Hong Kong ahora se consideran números internacionales.
Servicio de autenticación SMS de Aliyun (MAS): La firma ahora se ingresa como texto libre en vez de un desplegable, por lo que sigue funcionando si Aliyun vuelve a rotar las firmas.
Acción requerida — Protección SSRF del proveedor OIDC. Se ha reforzado la seguridad de las solicitudes salientes y ahora la protección SSRF está activada por defecto. Implementaciones autoalojadas que necesiten acceder a endpoints de partes confiables en redes privadas deben establecer OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true antes de arrancar Logto; de lo contrario, deja la variable sin definir.
Migración de base de datos necesaria. Esta versión incluye alteraciones de esquema para archivos de verificación de dominio personalizado, además de índices internos y tablas. Tras actualizar, ejecuta el comando de alteración de base de datos (npm run alteration deploy en la imagen @logto/cli/core, o logto db alteration deploy) antes de arrancar la nueva versión. Consulta la guía de actualización para más detalles.
Verificación personalizada de ID token. Consulta la sección anterior de node-oidc-provider v9 para ver los cambios en at_hash y el header typ.
