Logto v1.43.0 ajoute des applications dynamiques avec des documents de métadonnées OAuth Client ID, des requêtes d'authentification SAML signées, un runtime borné pour Custom JWT et Actions, une validation renforcée de l'échange de jetons, ainsi qu'une protection SSRF élargie pour les webhooks et le SSO d'entreprise.
CharlesDeveloper
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.43.0 élargit la façon dont les applications et les fournisseurs d'identité d'entreprise se connectent tout en renforçant les frontières de sécurité autour des jetons et des requêtes sortantes. Il introduit des applications dynamiques avec des documents de métadonnées OAuth Client ID, des requêtes d'authentification SAML signées et un runtime unifié pour les scripts Custom JWT et Actions. Cette version renforce également l'échange de jetons, les webhooks et le SSO entreprise, tout en apportant des améliorations au Centre de compte, la prise en charge de l'espagnol (Mexique), ainsi que des corrections de fiabilité. Voici ce qui est nouveau.
L'expérience de connexion prend désormais en charge es-MX (Espagnol, Mexique).
Pour les utilisateurs dont la langue est l'espagnol (Mexique), les champs de numéro de téléphone utilisent par défaut l'indicatif du Mexique (+52). Cette version corrige également les espaces réservés du formateur de listes et le dernier message MFA non traduit dans les locales espagnoles.
Protection SSRF pour les webhooks et le SSO d'entreprise#
Les requêtes sortantes configurées via l'API de gestion sont maintenant bloquées lorsqu'elles aboutissent à des adresses de boucle locale, privées, link-local, de métadonnées cloud ou autres adresses à usage spécial.
La protection couvre maintenant :
La livraison des webhooks, y compris POST /api/hooks/:id/test.
La découverte OIDC SSO entreprise, les requêtes de token et userinfo.
La récupération des métadonnées du fournisseur d'identité SAML.
Chaque redirection effectuée par ces requêtes.
Les noms DNS sont vérifiés lors de l'établissement de la connexion, donc un nom d'hôte qui résout vers une adresse protégée est rejeté, tout comme une adresse IP littérale.
En plus d'exiger des jetons sujets de première partie, Logto vérifie désormais qu'un JWT présenté comme un sujet access_token est bien un jeton d'accès.
Le JWT doit contenir :
L'entête type RFC 9068 at+jwt.
Une revendication client_id.
Les ID tokens OIDC et autres JWT signés par le locataire ne peuvent plus être utilisés à la place d'un jeton d'accès. Les jetons sujets invalides sont rejetés avec invalid_grant.
Restrictions API de compte pour les applications tierces#
Les applications tierces ne peuvent plus modifier les données de compte via l'API de compte ou l'API de vérification. Ces requêtes renvoient désormais :
Les applications de première partie, y compris le Centre de compte et la Console, ne sont pas affectées.
Le contrôle échoue par défaut pour les identifiants client non résolus. Cela inclut les applications supprimées dont les jetons d'accès sont encore actifs et les clients CIMD dont l'identifiant est une URL de métadonnées.
Aucune route de lecture n'a reçu de nouvelle protection directe. Toutefois, les lectures suivantes nécessitent des enregistrements de vérification créés via des routes protégées et ne sont donc plus accessibles par les applications tierces :
GET /api/my-account/grants
GET /api/my-account/sessions
GET /api/my-account/mfa-verifications/backup-codes
Les utilisateurs suspendus ne peuvent plus recevoir de nouveaux jetons#
L'émission de jeton et userinfo rejettent désormais les utilisateurs suspendus avec invalid_grant, en cohérence avec le comportement existant pour les utilisateurs supprimés.
Cela s'applique aux flux de refresh token, code d'autorisation, code d'appareil et échange de jetons, même si une révocation antérieure n'a pas abouti avec succès.
Retirer un scope utilisateur de la configuration de consentement d'une application tierce affecte désormais les autorisations existantes et les nouvelles demandes d'autorisation.
Les échanges de refresh token suppriment les scopes qui ne sont plus configurés.
Les demandes d'autorisation reprenant une autorisation existante échouent avec invalid_scope si nécessaire.
Les demandes de jetons d'organisation échouent avec insufficient_scope après la suppression du scope organizations.
La soumission du consentement n'accorde plus un scope supprimé alors que l'écran de consentement était ouvert.
Les verrous sur les identifiants utilisent des identifiants normalisés#
Les compteurs de blocage Sentinel utilisent maintenant la même forme d'identifiant normalisé que la recherche de compte :
Les adresses e-mail sont converties en minuscules.
Les numéros de téléphone sont mis en forme canonique.
Les noms d'utilisateur sont convertis selon la case uniquement si la politique du locataire est insensible à la casse.
Cela empêche différentes écritures d'un même identifiant de créer plusieurs compartiments et d'affaiblir maxAttempts.
Le déblocage manuel efface aussi les écritures équivalentes lorsque celles-ci identifient le même compte. Après mise à jour, un blocage existant sous une écriture non canonique peut se lever plus tôt, mais aucun utilisateur ne sera plus bloqué qu'avant.
Révoquer l'autorisation d'une application tierce pour un utilisateur n'invalide désormais que les jetons de cette application. La session SSO du navigateur de l'utilisateur reste active.
Les clés de signature à courbe elliptique annoncent désormais l'algorithme correspondant à leur courbe : P-256 utilise ES256, P-384 utilise ES384 et P-521 utilise ES512.
Passer de la connexion par passkey à la connexion par code de vérification ne bloque plus la réussite du CAPTCHA.
Les messages OIDC invalid_scope et insufficient_scope affichent maintenant le scope rejeté au lieu des placeholders bruts {{error_description}} ou {{scope}}.
Safari et d'autres gestionnaires de mots de passe peuvent désormais suggérer et enregistrer un mot de passe fort sur les écrans de définition et de réinitialisation du mot de passe en utilisant le bon identifiant de compte.
Les valeurs quality Accept-Language avec des espaces, comme en; q=0.7, sont désormais correctement analysées. Les valeurs de qualité invalides retombent proprement au lieu de donner NaN.
Le filtrage des listes d'autorisation et de blocage personnalisées Gmail considère désormais gmail.com et googlemail.com comme équivalents et ignore les points dans la partie locale.
La Console propose désormais des exemples plus clairs, des descriptions et des espaces réservés plus courts pour les règles de courriel personnalisées.
Enregistrer les réglages du Centre de compte ou de l'inscription supprime désormais les références aux champs de profil personnalisés supprimés au lieu de renvoyer custom_profile_fields.entity_not_exists_with_names.
Les champs supprimés restent supprimables de la Console même lorsque leur contrôle de permission est désactivé.
Les endpoints de relation de l'API de gestion acceptent maintenant des tableaux vides de scopes ou de rôles comme no-op au lieu de renvoyer une erreur 500. Ceci inclut des endpoints comme :
POST /applications/:applicationId/user-consent-scopes
POST /organizations/:id/users/:userId/roles
La validation de date vérifie maintenant tout l'entrée et rejette les caractères superflus après une date pourtant valide.
Les requêtes POST de webhooks sont désormais réessayées jusqu'à trois fois si l'endpoint renvoie une réponse HTTP 5xx, conformément au contrat de livraison documenté.
Comme un événement réessayé peut être livré plus d'une fois, les destinataires de webhooks doivent traiter les événements de manière idempotente.
Le connecteur Microsoft Azure AD prend maintenant en charge une option disableEmailSync.
Par défaut, le connecteur continue à copier l'attribut mail de Microsoft Graph dans le profil utilisateur Logto. Activez cette option lorsque le connecteur doit authentifier l'utilisateur sans synchroniser cette adresse, comme le permet déjà le SSO entreprise Azure OIDC.
Action requise — protection des requêtes sortantes: Si les webhooks ou les connecteurs SSO entreprise accèdent intentionnellement à des services sur un réseau privé, ajoutez les adresses IP ou plages CIDR requises à SSRF_ALLOWED_ADDRESSES avant la mise à jour :
Autoriser uniquement les destinations requises est plus sûr que de désactiver la protection globalement.
Compatibilité des applications dynamiques: Configurer SSRF_ALLOWED_ADDRESSES désactive CIMD donc les clients dynamiques non authentifiés ne peuvent pas utiliser la liste blanche pour atteindre des services privés. Régler SSRF_PROTECTION_DISABLED=true désactive aussi CIMD.
Compatibilité de configuration: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED reste pris en charge comme alias de SSRF_PROTECTION_DISABLED. Ces variables ne s'appliquent qu'aux déploiements auto-hébergés.
Limites du runtime de script : Les scripts Custom JWT et Actions doivent s'exécuter en moins de 5 secondes, rester dans une limite mémoire de 128 Mo, et retourner des valeurs sérialisables en JSON.
Migration de base de données requise : Cette version apporte de nouvelles modifications de schéma et de nouveaux index. Après mise à jour, lancez 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. Voir le guide de mise à jour.
