Explora nuestra versión de agosto de 2024 con suplantación de usuarios, gestión de secretos de aplicaciones, branding de la experiencia de inicio de sesión a nivel de organización y aplicación, y mucho más.
Se ha añadido soporte para la suplantación de usuarios mediante Intercambio de Tokens:
POST /subject-tokens para solicitar un subject_token para utilizar en el intercambio de tokens.POST /oidc/token con un nuevo tipo de concesión urn:ietf:params:oauth:grant-type:token-exchange para intercambiar un subject_token por un access_token suplantado de usuario.Consulta Suplantación de usuarios para más detalles.
custom_data a nivel de aplicaciónSe ha añadido un nuevo campo de objeto arbitrario custom_data a las aplicaciones. Este campo puede almacenar cualquier información adicional no definida en el esquema estándar Application.
PATCH /api/applications/{applicationId}/custom-data para actualizar el campo custom_data de una aplicación.PATCH /api/applications/{applicationId} para permitir la sobrescritura del campo custom_data.Se ha añadido un nuevo editor JSON de datos personalizados a la página de detalles de la aplicación (excepto para Aplicaciones Protegidas).
Las aplicaciones seguras (máquina-a-máquina, web tradicionales, Protegidas) ahora pueden tener múltiples secretos de aplicaciones con fecha de expiración. Esto permite la rotación de secretos y proporciona una experiencia aún más segura.
Nota: El secreto heredado creado antes de esta función todavía puede usarse para la autenticación del cliente. Sin embargo, se recomienda eliminar los antiguos y crear nuevos secretos con fecha de expiración para mejorar la seguridad.
GET /api/applications/{applicationId}/secrets: Lista todos los secretos de una aplicación.POST /api/applications/{applicationId}/secrets: Crea un nuevo secreto para una aplicación.DELETE /api/applications/{applicationId}/secrets/{name}: Elimina un secreto de una aplicación por nombre.PATCH /api/applications/{applicationId}/secrets/{name}: Actualiza un secreto de una aplicación por nombre.DELETE /api/applications/{applicationId}/legacy-secret: Elimina el secreto heredado de una aplicación y reemplázalo con uno nuevo.Para gestionar los secretos de tu aplicación, ve a la Consola de Logto -> Aplicaciones -> Detalles de la Aplicación -> Endpoints & Credenciales.
El campo de entrada del secreto de la aplicación original, que era de solo lectura, ha sido reemplazado por una nueva tabla de gestión de secretos. Puedes crear, actualizar y eliminar secretos en esta tabla.
Ahora es posible configurar logotipos claros y oscuros para las organizaciones. Puedes cargar los logotipos en la página de configuración de la organización.
Además, es posible sobrescribir el logotipo de la experiencia de inicio de sesión de una organización. Simplemente añade el parámetro organization_id a la solicitud de autenticación. En la mayoría de los SDK de Logto, esto se puede hacer usando el campo extraParams en el método signIn.
Por ejemplo, en el SDK de JavaScript:
El valor <organization-id> se puede encontrar en la página de configuración de la organización.
Si no encuentras el campo extraParams en el SDK que estás usando, por favor háznoslo saber.
Ahora puedes configurar logotipos, favicons y colores para tu aplicación. Estas configuraciones se utilizarán en la experiencia de inicio de sesión cuando la aplicación inicie el flujo de autenticación. Para aplicaciones que no tienen configuraciones de branding, se usará el branding de la experiencia de inicio de sesión omni.
Si se proporciona organization_id en la solicitud de autenticación, las configuraciones de branding a nivel de aplicación serán sobrescritas por las configuraciones de branding de la organización, si están disponibles.
Logto ahora inyecta las configuraciones y frases de la experiencia de inicio de sesión en el archivo index.html para mejorar el rendimiento de la primera pantalla. La aplicación de experiencia aún obtendrá las configuraciones y frases del servidor si:
tsup para construir los paquetes de conectores. Esto hará que el proceso de construcción sea más rápido y no debería afectar la funcionalidad de los paquetes.Vite para la transpilación y empaquetado de los paquetes @logto/console, @logto/demo-app y @logto/experience. Se eliminó ParcelJS y se reemplazó por Vite. No se esperan cambios rupturistas.PATCH /api/applications/{applicationId}Todos los campos jsonb del objeto Application deben actualizarse en modo replace en lugar de merge. Este cambio hará que el método PATCH sea más predecible y consistente con el diseño de la API Restful.
merge a replace en el punto de enlace PATCH /api/applications/{applicationId}.partial a full en el punto de enlace PATCH /api/applications/{applicationId}.oidc_client_metadata, custom_client_metadata, protected_app_metadata y custom_data.Nota: Si estás utilizando la consola de Logto para actualizar las configuraciones de
Application, no deberías verte afectado por este cambio. Los usuarios de la API que están usando el métodoPATCHpara actualizar las configuraciones de campo jsonb deApplicationdeben ser conscientes de este cambio. El métodoPATCHahora reemplazará todo el campo jsonb con los nuevos datos de entrada. Se rechazará cualquier dato de entrada parcial de los campos afectados.
Eventos de webhook afectados: Role.Scopes.Updated, Organizations.Membership.Updates.
El código de estado de la respuesta de la API devuelto por el payload del evento de webhook siempre era 404. Eso fue causado por insertar el payload del evento de webhook antes de que se configurara el contexto de la respuesta de la API.
Dado que solo activamos el webhook cuando el evento se procesa con éxito, el código de estado siempre debería ser 2xx.
Este problema se ha corregido moviendo la inserción del payload del evento de webhook después de que se configure el contexto de la respuesta de la API.
Argon2d y Argon2id. Los usuarios con esos algoritmos serán migrados a Argon2i tras un inicio de sesión exitoso.@logto/experience se ha sincronizado con lo que se indica en el README.md.