Logto v1.41.0 apporte le contrôle d'accès au niveau des applications, des politiques d'expiration des mots de passe, d'importantes améliorations du Centre de compte, des règles configurables pour les noms d'utilisateur et les codes de vérification, une livraison de messages plus sécurisée, ainsi qu'un renforcement des protocoles et de la sécurité.
SijieDeveloper
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.
Logto v1.41.0 est une version axée sur le contrôle et la sécurité. Elle offre aux équipes des moyens plus précis pour décider qui peut accéder à chaque application, un contrôle plus complet sur le cycle de vie des mots de passe, ainsi qu'un Centre de compte beaucoup plus performant pour les utilisateurs finaux. Elle renforce également la livraison des codes de vérification, les règles des noms d'utilisateur, la gestion SAML/OIDC, la protection contre la réutilisation MFA et les chemins de mise à jour pour le self-hosting. Voici les nouveautés.
Vous pouvez désormais restreindre l'accès à une application directement depuis Logto. Les règles d'accès peuvent cibler des utilisateurs spécifiques, des rôles utilisateur, des organisations ou des rôles d'organisation.
Lorsqu'un utilisateur ne correspond pas à l'ensemble des règles configurées, Logto bloque le flux de connexion ou d'accès à l'application avec une page d'accès refusé au lieu de laisser la demande se poursuivre. Cela simplifie le déploiement des applications, l'accès spécifique aux clients, la protection des outils internes et la gestion de l'accès limité à une organisation sans pousser la décision complète dans le code de ton application.
La Console prend désormais en charge l'expiration des mots de passe au niveau du locataire sous Sécurité > Politique de mot de passe.
Les administrateurs peuvent activer l'expiration des mots de passe, configurer le nombre de jours de validité d'un mot de passe et expirer manuellement le mot de passe d'un utilisateur spécifique depuis sa page de détails. Lorsqu'un mot de passe expire, l'utilisateur doit le réinitialiser via la méthode de récupération configurée avant de pouvoir continuer à se connecter par mot de passe.
Les connexions SSO et passkey ne sont pas affectées. Les utilisateurs existants sans date de changement de mot de passe enregistrée sont traités sans heurts : Logto les ancre à la date d'activation de la politique, afin qu'ils bénéficient de la période complète de validité au lieu d'être expirés immédiatement.
Plus de contrôles en libre-service dans le Centre de compte#
Le Centre de compte continue de devenir une véritable surface d'identité en libre-service pour les utilisateurs finaux.
Cette version ajoute la gestion des sessions, l'examen des applications tierces connectées, la gestion du profil, le téléchargement d'un avatar, le téléchargement d'un avatar lors de l'inscription avec collecte du profil, des contrôles indépendants pour les passkeys et une préférence utilisateur pour l'affichage de la fenêtre d'inscription par passkey.
La page profil du Centre de compte, les champs de profil personnalisés à l'inscription et les points de terminaison de téléchargement d'avatar sont désormais disponibles en dehors des portes de fonctionnalités en développement.
Quelques correctifs importants sont aussi inclus ici :
Le thème, la plateforme et la couleur de marque sont appliqués avant l'hydratation pour réduire l'effet de flash visuel.
La vérification step-up est limitée aux enregistrements de vérification de permission utilisateur.
Les identités sociales peuvent être liées sans vérification de mot de passe, d'email ou de téléphone lorsque l'utilisateur n'a aucune méthode de vérification de sécurité héritée.
L'édition du nom d'utilisateur depuis la console redirige désormais vers le Centre de compte pour que la vérification requise puisse être effectuée.
Politiques sur les noms d’utilisateur et les codes de vérification#
Les règles relatives aux noms d'utilisateur peuvent désormais être configurées au niveau du locataire dans Console > Expérience de connexion > Inscription/connexion > Options avancées.
La politique couvre la sensibilité à la casse, les limites de longueur et les types de caractères autorisés. Elle s'applique à toutes les écritures de nom d'utilisateur côté utilisateur final, y compris l'inscription, le remplissage de profil, le Centre de compte, l'API Account et /me.
Le passage aux noms d'utilisateur insensibles à la casse est protégé : Logto vérifie l'existence de noms d'utilisateur ne différant que par la casse et bloque le changement de politique tant que les conflits ne sont pas résolus. La revendication OIDC preferred_username utilise maintenant le username de l'utilisateur si profile.preferredUsername n'est pas défini.
Les contrôles des codes de vérification sont également déplacés dans les paramètres de sécurité de la console. Les administrateurs peuvent configurer la durée d'expiration des codes de vérification et le nombre maximal de tentatives de réessai.
Logto applique désormais une limite de fréquence d'envoi par destinataire au niveau du système sur les chemins d'envoi d'e-mails/SMS de vérification et d'invitation, incluant Expérience, MFA, Account API, Management API, /me, invitations d'organisation et l'API d'interaction héritée.
Lorsqu'un envoi est limité, Logto déclenche un événement webhook Message.RateLimited, qui est désormais sélectionnable dans les paramètres webhook de la Console.
La livraison des codes de vérification à des destinataires inconnus est également supprimée lorsque l'inscription est désactivée, réduisant ainsi le risque d'énumération de comptes.
Pour les tokens de ressource API d'organisation, le customizer de jeton d'accès JWT reçoit désormais context.organization avec l'id, le nom, la description et les customData de l'organisation ciblée.
Cela facilite l'ajout de revendications propres à chaque organisation sans devoir intégrer tous les mappings existants dans chaque jeton.
Quelques améliorations API notables sont aussi livrées :
POST /api/applications/:applicationId/roles est désormais idempotent. Les ID de rôles existants sont ignorés au lieu de retourner 422 application.role_exists.
Le point de terminaison renvoie maintenant 201 avec { roleIds, addedRoleIds }, en cohérence avec l'API d'affectation de rôles utilisateur.
La création de rôle d'organisation avec des portées initiales est désormais transactionnelle. Les ID de portées invalides ne laissent donc plus de rôles partiellement créés.
Cette version comprend un ensemble ciblé de corrections sur les protocoles et la sécurité :
Les formulaires auto-validés IdP SAML échappent désormais les attributs HTML et rejettent les URL d'action qui ne sont pas HTTP(S).
samlify est mis à jour en ^2.13.0 pour mieux échapper les assertions SAML XML générées.
La vérification TOTP MFA refuse les codes déjà utilisés du même compteur d'étape temporelle ou plus ancien.
Les corps de requête OIDC contenant des octets nuls retournent maintenant 400 invalid_request.
Les charges utiles du journal d'audit suppriment les octets nuls avant insertion.
Les vérifications de la blocklist de sous-adressage d'email ne construisent plus de regex à partir d'une entrée contrôlée par l'utilisateur.
Logto Tunnel empêche les requêtes de fichiers statiques de lire en dehors du chemin d'expérience configuré.
Des correctifs de compatibilité et stockage sont inclus aussi : les versions Safari anciennes et iOS 15 ne crashent plus au démarrage à cause de la syntaxe lookbehind regex non prise en charge, les connecteurs d'entreprise OIDC peuvent obtenir la configuration discovery auprès de fournisseurs qui refusent la négociation JSON-only, et les erreurs de transport d'actifs UI personnalisés Azure Blob sont maintenant mappées sur des erreurs téléchargeables et retentables.
Une migration de base de données est requise pour v1.41.0. Cette version comprend des changements de schéma pour l'expiration des mots de passe, la politique des noms d'utilisateur, la politique des codes de vérification, les index sentinelles de taux de messages, les valeurs par défaut du Centre de compte et les index de logs de service.
Après la mise à niveau, exécute la commande d'altération de base avant de démarrer la nouvelle version. Consulte le guide de mise à niveau pour plus de détails.
La variable d'environnement CASE_SENSITIVE_USERNAME est désormais obsolète. Elle fonctionne toujours comme override à l'exécution, mais la sensibilité à la casse des noms d'utilisateur doit être configurée par locataire via la nouvelle politique de nom d'utilisateur. La variable sera supprimée dans la prochaine version majeure.
