Logto v1.43.0 añade aplicaciones dinámicas con Documentos de Metadatos de ID de cliente OAuth, solicitudes de autenticación SAML firmadas, un runtime acotado para JWT personalizados y Actions, validación más estricta en el intercambio de tokens, y protección SSRF ampliada para webhooks y SSO empresarial.
CharlesDeveloper
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.43.0 amplía cómo las aplicaciones y los proveedores de identidad empresariales se conectan, mientras fortalece los límites de seguridad alrededor de los tokens y solicitudes salientes. Introduce aplicaciones dinámicas con Documentos de Metadatos de ID de cliente OAuth, solicitudes de autenticación SAML firmadas y un runtime consolidado para JWT personalizados y Actions. El lanzamiento también refuerza el intercambio de tokens, webhooks y SSO empresarial, junto con mejoras en el Centro de Cuenta, soporte en español (México) y correcciones de fiabilidad. Veamos las novedades.
La experiencia de inicio de sesión ahora soporta es-MX (español, México).
Para los usuarios cuyo idioma es español (México), la entrada de teléfono por defecto trae el código de país de México (+52). Este lanzamiento también corrige los placeholders en el formato de listas y el mensaje MFA restante que no estaba traducido en los locales en español.
Las solicitudes salientes configuradas a través de la API de gestión ahora son bloqueadas cuando resuelven hacia direcciones loopback, privadas, link-local, metadatos en la nube u otras direcciones de uso especial.
La protección cubre ahora:
Entrega de webhooks, incluyendo POST /api/hooks/:id/test.
Descubrimiento OIDC SSO empresarial, token y solicitudes userinfo.
Obtención de metadatos de proveedores de identidad SAML.
Cada salto de redirección realizada por estas solicitudes.
Los nombres DNS se verifican al establecer la conexión, por lo que un nombre de host que resuelve a una dirección protegida es rechazado igual que una IP literal.
Además de requerir tokens de sujeto de primera parte, Logto ahora valida que un JWT presentado como sujeto access_token sea realmente un token de acceso.
El JWT debe contener:
El encabezado de tipo RFC 9068 at+jwt.
Un claim client_id.
Los tokens ID OIDC y otros JWTs firmados por el tenant ya no pueden ser sustituidos por un token de acceso. Los tokens de sujeto inválidos se rechazan con invalid_grant.
Las aplicaciones de terceros ya no pueden alterar datos de cuentas a través de la Account API ni de la Verification API. Ahora dichas solicitudes retornan:
Las aplicaciones de primera parte, como el Centro de Cuenta y la Consola, no se ven afectadas.
La verificación falla cerrada para identificadores de cliente no resueltos. Esto incluye aplicaciones eliminadas cuyos tokens de acceso todavía están activos y clientes CIMD cuyo identificador es una URL de metadatos.
Ninguna ruta de lectura recibió una nueva protección directa. Sin embargo, las siguientes lecturas requieren registros de verificación creados a través de rutas protegidas y por lo tanto ya no son accesibles para aplicaciones de terceros:
GET /api/my-account/grants
GET /api/my-account/sessions
GET /api/my-account/mfa-verifications/backup-codes
Usuarios suspendidos no pueden recibir nuevos tokens#
La emisión de tokens y userinfo ahora rechazan usuarios suspendidos con invalid_grant, igualando el comportamiento existente para usuarios eliminados.
Esto aplica para los flujos de token de refresh, código de autorización, device code e intercambio de token, incluso si una revocación de token o sesión anterior no se completó con éxito.
Los scopes de aplicaciones de terceros se revalidan#
Remover un scope de usuario de la configuración de consentimiento de una aplicación de terceros ahora afecta tanto a autorizaciones existentes como a nuevas solicitudes.
Los intercambios de refresh token descartan los scopes ya no configurados.
Las solicitudes de autorización que reanuden una autorización existente fallan con invalid_scope cuando corresponde.
Las solicitudes de token de organización fallan con insufficient_scope tras remover el scope de organizaciones.
El envío del consentimiento ya no otorga un scope que fue eliminado mientras la pantalla de consentimiento estaba abierta.
Los bloqueos de identificador usan identificadores normalizados#
Los contadores de bloqueo Sentinel ahora usan la misma forma de identificador normalizada que la búsqueda de cuenta:
Correos electrónicos en minúscula.
Números de teléfono canonizados.
Usernames convierten mayúsculas a minúsculas sólo cuando la política de username del tenant es insensible a mayúsculas.
Esto previene que diferentes formas de un mismo identificador creen contenedores de intento separados y debiliten maxAttempts.
El desbloqueo manual también limpia las variantes ortográficas equivalentes donde identifican la misma cuenta. Tras la actualización, un bloqueo existente registrado bajo una ortografía no canónica puede terminar antes, pero ningún usuario quedará más bloqueado que antes.
Revocar la autorización de aplicación de terceros de un usuario ahora sólo invalida los tokens de esa aplicación. La sesión SSO del usuario en el navegador permanece activa.
Las llaves de firma de Curva Elíptica ahora anuncian el algoritmo correspondiente a su curva: P-256 usa ES256, P-384 usa ES384 y P-521 usa ES512.
Cambiar de inicio de sesión con passkey a código de verificación ya no impide que los usuarios completen el CAPTCHA.
Los mensajes OIDC invalid_scope e insufficient_scope ahora muestran el scope rechazado en vez de los placeholders crudos {{error_description}} o {{scope}}.
Safari y otros gestores de contraseñas ahora pueden sugerir y guardar una contraseña fuerte en las pantallas de establecer o restablecer contraseña usando el identificador de cuenta correcto.
Los valores de calidad de Accept-Language con espacios, como en; q=0.7, ahora se analizan correctamente. Los valores de calidad inválidos hacen fallback de forma segura en vez de producir NaN.
El emparejamiento personalizado de allowlist y blocklist de Gmail ahora trata gmail.com y googlemail.com como equivalentes e ignora puntos en la parte local.
La Consola ahora muestra ejemplos, descripciones y placeholders más cortos y claros para reglas de correo personalizadas.
Al guardar la configuración del Account Center o de registro, ahora se eliminan referencias a campos de perfil personalizados eliminados, en vez de devolver custom_profile_fields.entity_not_exists_with_names.
Los campos eliminados siguen siendo removibles desde la Consola incluso si su control de permiso está en Off.
Los endpoints de relaciones en la Management API ahora aceptan arreglos vacíos de scope o roles como no-ops en vez de retornar un error 500. Esto incluye endpoints como:
POST /applications/:applicationId/user-consent-scopes
POST /organizations/:id/users/:userId/roles
La validación de fechas ahora coincide con toda la entrada y rechaza caracteres finales después de una fecha válida.
Las solicitudes POST de webhook ahora intentan nuevamente hasta tres veces cuando el endpoint retorna una respuesta HTTP 5xx, siguiendo el contrato documentado de entregas.
Dado que un evento reintentado puede ser entregado más de una vez, los receptores de webhooks deben procesar los eventos de manera idempotente.
El conector de Microsoft Azure AD ahora soporta una opción disableEmailSync.
Por defecto, el conector continúa copiando el atributo mail de Microsoft Graph al perfil de usuario de Logto. Activa esta opción si el conector debe autenticar al usuario sin sincronizar esa dirección, igualando el control ya disponible para el SSO empresarial Azure OIDC.
Acción requerida — protección de solicitudes salientes: Si los webhooks o conectores SSO empresariales acceden intencionadamente a servicios en una red privada, añade las IPs o rangos CIDR requeridos a SSRF_ALLOWED_ADDRESSES antes de actualizar:
Permitir solo los destinos requeridos es más seguro que deshabilitar la protección global.
Compatibilidad de apps dinámicas: Configurar SSRF_ALLOWED_ADDRESSES desactiva CIMD para que clientes dinámicos no autenticados no puedan usar la allowlist para alcanzar servicios privados. Establecer SSRF_PROTECTION_DISABLED=true también desactiva CIMD.
Compatibilidad de configuración: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED sigue soportado como alias de SSRF_PROTECTION_DISABLED. Estas variables sólo aplican para despliegues auto-alojados.
Límites de runtime para scripts: Los scripts de JWT personalizados y Actions deben completarse en 5 segundos, mantenerse dentro del presupuesto de 128 MB de memoria de worker y retornar valores serializables como JSON.
Migración de base de datos requerida: Este lanzamiento trae alteraciones e índices nuevos en el esquema. 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 iniciar la nueva versión. Consulta la guía de actualización.
