Logto v1.42.0 apporte des fichiers de vérification de domaine personnalisé, des listes blanches d’e-mails avec motifs génériques (wildcard), des liens magiques de réinitialisation de mot de passe, un webhook Grant.LimitExceeded, et une mise à jour du protocole avec node-oidc-provider v9, Koa 3 et la protection SSRF activée par défaut.
SimengDeveloper
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.42.0 est une version axée sur les domaines et les protocoles. Elle permet aux équipes de prouver la propriété d’un domaine sans mettre en place un nouvel hôte, d’avoir un contrôle plus précis sur les e-mails autorisés dans un tenant, et d’offrir un chemin plus fluide de réinitialisation de mot de passe pour les utilisateurs finaux. Sous le capot, Logto passe à node-oidc-provider v9 et Koa 3, et active la protection SSRF pour les requêtes OIDC sortantes par défaut. Voici les nouveautés.
Les services tiers vérifient souvent la propriété d’un domaine en demandant de servir un petit fichier à un chemin fixe. Jusqu’à présent, cela signifiait devoir exécuter un hôte séparé avec votre domaine personnalisé Logto.
Vous pouvez désormais joindre des fichiers de vérification à un domaine personnalisé actif dans Console > Paramètres du tenant > Domaines. Chaque fichier comporte :
Un chemin qui est soit un nom de fichier racine avec une extension (par exemple /verify.txt), soit un chemin sous /.well-known/.
Un type de contenu text/plain ou application/json. Le contenu JSON est validé à l’enregistrement.
Un contenu jusqu’à 16 Ko.
Jusqu’à 10 fichiers par domaine peuvent être configurés, et les chemins doivent être uniques. Logto sert exactement les requêtes GET et HEAD correspondant au type de contenu configuré, avec renforcement de la réponse. Les routes Logto existantes prennent toujours le dessus sur un fichier de vérification au même chemin, donc un fichier mal configuré ne pourra jamais masquer un véritable endpoint. L’expérience Console est localisée dans toutes les langues supportées.
Comme Logto ne touche pas au contenu du fichier, cela fonctionne avec n’importe quel schéma de vérification de fournisseur, sans que Logto ait à modéliser un comportement spécifique à un provider.
Règles d’accès e-mail : listes blanches et motifs génériques#
La politique de liste noire d’e-mails devient un ensemble complet de règles d’accès e-mail, configurées dans Console > Sécurité > Liste noire d’e-mails.
Liste blanche d’e-mails personnalisée. Configurez une liste blanche d’adresses e-mail, de domaines ou de motifs génériques. Lorsque la liste blanche est définie, seuls les emails correspondants sont acceptés pour les nouvelles inscriptions et pour les nouveaux e-mails liés — aussi bien lors de l’enregistrement par e-mail que lors des mises à jour de l’adresse du compte.
Motifs génériques (wildcard). La liste blanche et la liste noire acceptent tous deux des motifs génériques sur les adresses et les domaines e-mail, tels que foo*@example.com, *@example.com, et @*.example.com, en plus des adresses exactes ([email protected]) et des domaines (@example.com).
Avertissements de conflit. La console avertit lorsqu’une entrée de liste blanche correspond aussi à une règle de blocage, lorsqu’une entrée de liste blanche utilise un plus alors que le subaddressing est bloqué, ou lorsque les règles combinées n’autoriseraient plus aucun nouvel e-mail.
La logique de correspondance et de validation est partagée via des helpers réutilisables dans @logto/core-kit, donc les mêmes règles s’appliquent partout où un e-mail entre dans un tenant.
Liens magiques de réinitialisation de mot de passe#
L’application Experience prend désormais en charge les parcours de réinitialisation de mot de passe qui vérifient les liens magiques à usage unique directement depuis la page d’atterrissage, en plus des codes de vérification.
Lorsque des grants OIDC sont évincés parce qu’une application a dépassé la limite maximale autorisée, Logto déclenche maintenant un événement webhook Grant.LimitExceeded, sélectionnable depuis les paramètres des webhooks Console comme n’importe quel autre événement.
La charge utile inclut userId, applicationId, revokedGrantIds, maxAllowedGrants et preRevocationActiveGrantCount. La diffusion est en mode "fire-and-forget" : les échecs sont consignés comme entrées de journal d’audit TriggerHook.Grant.LimitExceeded et ne bloquent jamais la réponse d’authentification.
Fournisseur OIDC mis à jour vers node-oidc-provider v9#
La principale modification ici est un correctif de sécurité sur la révocation de jetons.
La révocation d’un jeton opaque d’accès révoque maintenant tous les tokens du même grant, y compris le refresh token. En v8, le token de rafraîchissement restait utilisable après révocation et pouvait continuer à demander de nouveaux jetons d’accès.
Autres mises à jour du protocole en v9 :
Le endpoint de révocation rejette désormais les jetons d’accès JWT avec unsupported_token_type, au lieu de retourner un succès sans révoquer quoi que ce soit comme en v8.
L’endpoint de métadonnées de serveur d’autorisation selon RFC 8414 est disponible à /oidc/.well-known/oauth-authorization-server.
La claim redondante at_hash est retirée des jetons d’ID émis au token endpoint.
Les jetons d’ID n’incluent plus l’en-tête optionnel typ: "JWT". OpenID Connect définit les jetons d’ID comme JWT, et ne requiert pas que les clients vérifient cet en-tête.
Action requise pour la vérification personnalisée des jetons d’ID. Aucune action nécessaire si tu utilises un SDK Logto officiel. Si ton intégration effectue une vérification personnalisée du jeton d’ID, adapte-la pour accepter l’absence du champ at_hash et de l’en-tête typ: "JWT".
Logto tourne désormais sur Koa 3, la ligne de version maintenue activement et recevant les correctifs de sécurité en priorité. Aucun changement de comportement attendu : tous les endpoints, flux OIDC, et réponses API fonctionnent comme avant.
Les secrets d’application internes ne sont plus exposés via les APIs de gestion.
La politique de liste noire d’e-mails n’est plus renvoyée dans les réponses publiques de l’expérience de connexion.
Récupérer les tokens d’accès de provider tiers via l’API Account requiert désormais le scope utilisateur identities, comme les autres endpoints SSO sociaux et entreprises.
Les codes de vérification de l’API Account ne sont plus envoyés aux adresses e-mail bloquées.
La validation des adresses e-mail et des domaines e-mail correspond maintenant aux valeurs complètes et impose des labels de domaine plus stricts.
Correctifs sur l’expérience, le stockage et la stabilité#
Lorsqu’un parcours d’enregistrement social ou SSO est refusé par les règles d’accès e-mail, reconnaître l’erreur ramène désormais l’utilisateur à la page de connexion Logto au lieu de retourner chez le fournisseur d’identité externe.
L’authentification MFA est maintenant activée automatiquement juste après qu’un utilisateur ait lié un facteur via les APIs Account.
Créer un nouveau connecteur e-mail ou SMS exécute l’insertion et le nettoyage des anciens connecteurs dans une seule transaction base de données. Auparavant, un crash entre les deux opérations pouvait laisser des connecteurs dupliqués.
Les identifiants de cluster Redis sont désormais décodés en pourcentage, ce qui permet la connexion lorsque le nom d’utilisateur ou le mot de passe contient des caractères réservés à l’URL.
TLS est désormais correctement activé pour les connexions cluster Redis qui utilisent le protocole rediss.
jose v6 : Les connecteurs Apple, Google, OAuth et OIDC utilisent maintenant jose 6, qui fonctionne avec l’API Web Crypto au lieu du module crypto de Node. La signature des jetons et la vérification des ID tokens restent inchangées.
GitLab : Suppression de la dépendance jose inutilisée, ainsi l’installation du connecteur n’embarque plus de package inutile.
Aliyun SMS : Les numéros de téléphone de Hong Kong sont maintenant considérés comme internationaux.
Aliyun SMS authentication service (MAS) : La signature est désormais saisie en texte libre plutôt que sélectionnée dans une liste déroulante, donc ça continue de fonctionner si Aliyun effectue une rotation des signatures.
Action requise — Protection SSRF du fournisseur OIDC. La sécurité des requêtes sortantes est renforcée et la protection SSRF est maintenant activée par défaut. Si ton déploiement auto-hébergé doit accéder à des endpoints de tierces parties de confiance sur des réseaux privés, tu dois définir OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true avant de démarrer Logto ; sinon, laisse la variable désactivée.
Migration de base de données requise. Cette version embarque des modifications de schéma pour les fichiers de vérification de domaine personnalisé, ainsi que des index et tables internes. Après la mise à jour, exécute la commande d’altération de base de données (npm run alteration deploy dans l’image @logto/cli/core, ou logto db alteration deploy) avant de démarrer la nouvelle version. Consulte le guide de mise à niveau pour plus de détails.
Vérification personnalisée des jetons d’ID. Voir la section node-oidc-provider v9 ci-dessus pour les changements sur at_hash et l’en-tête typ.
