Logto v1.43.0 aggiunge app dinamiche con OAuth Client ID Metadata Documents, richieste di autenticazione SAML firmate, un runtime limitato per Custom JWT e Actions, una validazione più rigorosa dello scambio di token e una protezione SSRF ampliata per webhook e SSO aziendale.
CharlesDeveloper
Smetti di sprecare settimane sull'autenticazione degli utenti
Lancia app sicure più velocemente con Logto. Integra l'autenticazione degli utenti in pochi minuti e concentrati sul tuo prodotto principale.
Logto v1.43.0 amplia il modo in cui le applicazioni e i provider di identità aziendali si connettono, rafforzando i confini di sicurezza intorno ai token e alle richieste in uscita. Introduce app dinamiche con OAuth Client ID Metadata Documents, richieste di autenticazione SAML firmate e un runtime consolidato per Custom JWT e Actions. Il rilascio migliora anche la sicurezza di scambio token, webhook e SSO aziendale, con miglioramenti all'Account Center, supporto per lo spagnolo (Messico) e correzioni di affidabilità. Ecco le novità.
L'esperienza di accesso ora supporta es-MX (spagnolo, Messico).
Per gli utenti la cui lingua è lo spagnolo (Messico), i numeri di telefono predefiniti avranno il prefisso paese del Messico (+52). Questa versione corregge inoltre i segnaposto del formattatore elenco e l'ultimo messaggio MFA non tradotto nelle localizzazioni spagnole.
Le richieste in uscita configurate tramite la Management API ora sono bloccate se vengono risolte verso loopback, indirizzi privati, link-local, metadati cloud o altri indirizzi a uso speciale.
La protezione copre ora:
Consegna webhook, inclusi POST /api/hooks/:id/test.
Scoperta OIDC enterprise SSO, richieste token e userinfo.
Recupero dei metadati del provider di identità SAML.
Ogni salto di redirect effettuato da queste richieste.
I nomi DNS vengono controllati quando viene stabilita la connessione, quindi un hostname che risolve verso un indirizzo protetto viene rifiutato come un indirizzo IP letterale.
Oltre a richiedere subject token di prima parte, ora Logto valida che un JWT presentato come un subject access_token sia effettivamente un access token.
Il JWT deve contenere:
L'header type at+jwt secondo RFC 9068.
Una claim client_id.
I token ID OIDC e altri JWT firmati dal tenant non possono più essere sostituiti a un access token. I subject token non validi vengono rifiutati con invalid_grant.
Le applicazioni di terze parti non possono più modificare i dati account tramite Account API o Verification API. Tali richieste ora restituiscono:
Le applicazioni di prima parte, incluso Account Center e Console, non sono interessate.
Il controllo fallisce chiuso per identificatori cliente non risolti. Questo include applicazioni eliminate i cui access token sono ancora attivi e i client CIMD il cui identificatore è un URL di metadati.
Nessuna rotta di lettura ha ricevuto una nuova protezione diretta. Tuttavia, le seguenti letture richiedono record di verifica creati tramite rotte protette e quindi non sono più accessibili da app di terze parti:
GET /api/my-account/grants
GET /api/my-account/sessions
GET /api/my-account/mfa-verifications/backup-codes
Gli utenti sospesi non possono ricevere nuovi token#
L'emissione dei token e userinfo ora rifiuta utenti sospesi con invalid_grant, in linea con il comportamento esistente per gli utenti eliminati.
Questo vale per refresh token, authorization code, device code e flussi di token exchange, anche se una revoca precedente di token/sessione non è stata completata correttamente.
Gli scope delle app di terze parti vengono rivalidati#
La rimozione di uno scope utente dalla configurazione del consenso di un'app di terze parti ora ha effetto sia sui permessi già concessi che sulle nuove richieste di autorizzazione.
Gli scambi di refresh token rimuovono gli scope non più configurati.
Le richieste di autorizzazione che riattivano un permesso esistente falliscono con invalid_scope quando appropriato.
Le richieste token delle organizzazioni falliscono con insufficient_scope dopo che lo scope di organizzazione è stato rimosso.
L'invio del consenso non concede più uno scope rimosso mentre la schermata di consenso era aperta.
I blocchi per identificatori usano identificatori normalizzati#
I contatori di blocco tramite Sentinel ora usano la stessa forma normalizzata degli identificatori utilizzata per la ricerca account:
Gli indirizzi email sono messi in minuscolo.
I numeri di telefono sono canonizzati.
I nomi utente considerano i caratteri maiuscoli/minuscoli solo se la policy tenant lo prevede.
Questo impedisce che varianti alternative dello stesso identificatore creino bucket di tentativi separati, indebolendo maxAttempts.
Lo sblocco manuale cancella anche le varianti equivalenti ove si riferiscano allo stesso account. Dopo l'aggiornamento, un blocco esistente registrato sotto una variante non canonica può terminare prima del previsto, ma nessun utente sarà più bloccato di prima.
Safari e altri password manager possono ora suggerire e salvare una password forte nelle schermate di impostazione/reset password usando l'identificatore corretto dell'account.
I valori di qualità Accept-Language con spazi, come en; q=0.7, sono ora analizzati correttamente. I valori di qualità non validi ricadono su impostazioni sicure invece di produrre NaN.
L'abbinamento personalizzato alla allowlist e blocklist Gmail ora considera gmail.com e googlemail.com equivalenti e ignora i punti nella parte locale.
La Console ora mostra esempi più chiari, descrizioni e segnaposto più brevi per regole personalizzate delle email.
Il salvataggio delle impostazioni di Account Center o di iscrizione ora elimina i riferimenti ai campi profilo personalizzati eliminati invece di restituire custom_profile_fields.entity_not_exists_with_names.
I campi eliminati restano rimovibili dalla Console anche quando il controllo permessi è su Off.
Gli endpoint di relazione della Management API ora accettano array vuoti di scope o ruoli come no-op invece di restituire un errore 500. Questo include endpoint come:
POST /applications/:applicationId/user-consent-scopes
POST /organizations/:id/users/:userId/roles
La validazione delle date ora verifica l'intero input e rifiuta caratteri in eccesso dopo una data comunque valida.
Le richieste POST dei webhook ora vengono ripetute fino a tre volte quando l'endpoint restituisce una risposta HTTP 5xx, in linea con quanto descritto nel contratto di consegna.
Poiché un evento ritentato potrebbe essere consegnato più volte, i ricevitori webhook dovrebbero elaborare gli eventi in modo idempotente.
Il connettore Microsoft Azure AD ora supporta un'opzione disableEmailSync.
Per default, il connettore continua a copiare l'attributo mail da Microsoft Graph nel profilo utente Logto. Attiva questa opzione se desideri che il connettore autentichi l'utente senza sincronizzare quell'indirizzo, come previsto dall'impostazione esistente per SSO enterprise OIDC Azure.
Azione richiesta — protezione richieste uscenti: se i webhook o i connettori SSO aziendali accedono intenzionalmente a servizi su una rete privata, aggiungi gli indirizzi IP o le CIDR richieste a SSRF_ALLOWED_ADDRESSES prima dell'aggiornamento:
Consentire solo le destinazioni necessarie è più sicuro che disabilitare la protezione globalmente.
Compatibilità app dinamiche: La configurazione di SSRF_ALLOWED_ADDRESSES disabilità CIMD affinché i client dinamici non autenticati non possano usare la allowlist per raggiungere servizi privati. Impostando anche SSRF_PROTECTION_DISABLED=true si disabilita CIMD.
Compatibilità configurazione: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED resta supportato come alias di SSRF_PROTECTION_DISABLED. Queste variabili valgono solo per deployment self-hosted.
Limiti runtime script: Gli script Custom JWT e Actions devono completarsi entro 5 secondi, restare entro il limite di memoria worker di 128 MB e restituire valori serializzabili in JSON.
Richiesta migrazione database: Questa versione include nuove alterazioni di schema e indici. Dopo l'aggiornamento, esegui il comando di alterazione database (npm run alteration deploy nell'immagine @logto/cli/core, o logto db alteration deploy) prima di avviare la nuova versione. Consulta la guida all'aggiornamento.
