Français
  • release

Mises à jour du produit Logto (août 2024)

Découvrez notre version d'août 2024 avec l'usurpation d'identité utilisateur, la gestion des secrets d'application, la personnalisation de l'expérience de connexion au niveau de l'organisation et de l'application, et bien plus encore.

Simeng
Simeng
Developer

Arrêtez de perdre des semaines sur l'authentification des utilisateurs
Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.
Commencer
Product screenshot

Usurpation d'identité utilisateur (RFC 8693 : Échange de jetons OAuth 2.0)

Ajout du support pour l'usurpation d'identité utilisateur via l'échange de jetons :

  • Nouveau point de terminaison de l'API de gestion POST /subject-tokens pour demander un subject_token à utiliser lors de l'échange de jetons.
  • Mise à jour du point de terminaison OIDC POST /oidc/token avec un nouveau type de subvention urn:ietf:params:oauth:grant-type:token-exchange pour échanger un subject_token contre un access_token usurpé par l'utilisateur.

Voir Usurpation d'identité utilisateur pour plus de détails.

custom_data au niveau de l'application

Ajout d'un nouveau champ d'objet arbitraire custom_data aux applications. Ce champ peut stocker toute information supplémentaire non définie dans le schéma standard d'Application.

Cliquez pour développer les mises à jour de l'API de gestion
  • Nouveau point de terminaison PATCH /api/applications/{applicationId}/custom-data pour mettre à jour le champ custom_data d'une application.
  • Mise à jour du point de terminaison PATCH /api/applications/{applicationId} pour permettre l'écrasement du champ custom_data.
Cliquez pour développer les mises à jour de la console

Ajout d'un nouvel éditeur JSON de données personnalisées à la page de détails de l'application (à l'exception des applications protégées).

Gestion des multiples secrets d'application

Les applications sécurisées (machine-machine, web traditionnelles, protégées) peuvent désormais avoir plusieurs secrets d'application avec expiration. Cela permet la rotation des secrets et offre une expérience encore plus sécurisée.

Remarque : Le secret hérité créé avant cette fonctionnalité peut encore être utilisé pour l'authentification client. Cependant, il est recommandé de supprimer les anciens et de créer de nouveaux secrets avec expiration pour une sécurité améliorée.

Cliquez pour développer les mises à jour de l'API de gestion
  • GET /api/applications/{applicationId}/secrets : Listez tous les secrets d'une application.
  • POST /api/applications/{applicationId}/secrets : Créez un nouveau secret pour une application.
  • DELETE /api/applications/{applicationId}/secrets/{name} : Supprimez un secret d'une application par son nom.
  • PATCH /api/applications/{applicationId}/secrets/{name} : Mettez à jour un secret d'une application par son nom.
  • DELETE /api/applications/{applicationId}/legacy-secret : Supprimez le secret hérité d'une application et remplacez-le par un nouveau.
Cliquez pour développer les mises à jour de la console

Pour gérer vos secrets d'application, allez à Logto Console -> Applications -> Détails de l'application -> Endpoints & Credentials.

Le champ d'entrée du secret d'application en lecture seule a maintenant été remplacé par une nouvelle table de gestion des secrets. Vous pouvez créer, mettre à jour et supprimer des secrets dans cette table.

Personnalisation au niveau de l'organisation et de l'application

Logo de l'organisation

Il est maintenant possible de définir des logos clairs et sombres pour les organisations. Vous pouvez télécharger les logos dans la page des paramètres de l'organisation.

Il est également possible de remplacer le logo de l'expérience de connexion d'une organisation. Il suffit d'ajouter le paramètre organization_id à la demande d'authentification. Dans la plupart des SDK Logto, cela peut être fait en utilisant le champ extraParams dans la méthode signIn.

Par exemple, dans le SDK JavaScript :

La valeur <organization-id> peut être trouvée dans la page des paramètres de l'organisation.

Si vous ne trouvez pas le champ extraParams dans le SDK que vous utilisez, veuillez nous en informer.

Personnalisation au niveau de l'application

Vous pouvez désormais définir des logos, des favicons et des couleurs pour votre application. Ces paramètres seront utilisés dans l'expérience de connexion lorsque l'application initie le flux d'authentification. Pour les applications qui n'ont pas de paramètres de personnalisation, la personnalisation de l'expérience de connexion omni sera utilisée.

Si organization_id est fourni dans la demande d'authentification, les paramètres de personnalisation au niveau de l'application seront remplacés par les paramètres de personnalisation de l'organisation, si disponibles.

Améliorations des performances

Support de l'expérience de rendu côté serveur de l'application

Logto injecte maintenant les paramètres et les phrases de l'expérience de connexion dans le fichier index.html pour une meilleure performance du premier écran. L'application d'expérience récupérera toujours les paramètres et les phrases depuis le serveur si :

  • Le serveur n'a pas injecté les paramètres et les phrases.
  • Les paramètres dans l'URL sont différents des données rendues côté serveur.

Améliorations de la construction des packages

  • Utilisez tsup pour construire les packages de connecteurs. Cela rendra le processus de construction plus rapide, et ne devrait pas affecter la fonctionnalité des packages.
  • Utilisez Vite pour la transpilation et le bundling des packages @logto/console, @logto/demo-app et @logto/experience. Suppression de ParcelJS et remplacement par Vite. Aucun changement majeur à prévoir.

Corrections de bugs

Correction du comportement de mise à jour jsonb du point de terminaison PATCH /api/applications/{applicationId}

Tous les champs jsonb de l'objet Application doivent être mis à jour en mode replace au lieu du mode merge. Ce changement rendra la méthode PATCH plus prévisible et cohérente avec la conception de l'API Restful.

  • Mise à jour du mode de mise à jour de champ jsonb de merge à replace dans le point de terminaison PATCH /api/applications/{applicationId}.
  • Mise à jour de la validation des paramètres d'entrée des champs jsonb de l'API de partiel à complet dans le point de terminaison PATCH /api/applications/{applicationId}.
  • Champs affectés : oidc_client_metadata, custom_client_metadata, protected_app_metadata et custom_data.

Remarque : Si vous utilisez la console Logto pour mettre à jour les paramètres de l'Application, vous ne devriez pas être affecté par ce changement. Les utilisateurs de l'API qui utilisent la méthode PATCH pour mettre à jour les paramètres de champ jsonb de l'Application devraient être au courant de ce changement. La méthode PATCH remplacera maintenant tout le champ jsonb par les nouvelles données d'entrée. Toute donnée d'entrée partielle des champs affectés sera rejetée.

Correction de l'événement webhook où la charge utile renvoie toujours le statut de réponse API 404

Événements webhook affectés : Role.Scopes.Updated, Organizations.Membership.Updates.

Le code statut de la réponse API renvoyé par la charge utile de l'événement webhook était toujours de 404. Cela était dû à l'insertion de la charge utile de l'événement webhook avant que le contexte de réponse API ne soit défini.

Étant donné que nous ne déclenchons le webhook que lorsque l'événement est traité avec succès, le code statut devrait toujours être de 2xx.

Ce problème a été corrigé en déplaçant l'insertion de la charge utile de l'événement webhook après que le contexte de réponse API soit défini.

Autres améliorations

  • Le favicon pour le thème sombre peut maintenant être défini dans les paramètres de personnalisation de l'expérience de connexion.
  • Ajout de nouveaux algorithmes de hachage pour le mot de passe : Argon2d et Argon2id. Les utilisateurs avec ces algorithmes seront migrés vers Argon2i après une connexion réussie.
  • La configuration de la liste des navigateurs pour @logto/experience a été synchronisée avec ce qui est indiqué dans README.md.
  • Amélioration de la description de l'authentification Swagger. Utiliser le schéma de sécurité OAuth2 natif d'OpenAPI au lieu du schéma de sécurité basé sur l'en-tête HTTP personnalisé.