Logto v1.41.0 introduce il controllo degli accessi a livello di applicazione, politiche di scadenza della password, importanti aggiornamenti al Centro Account, regole configurabili per nome utente e codice di verifica, consegna dei messaggi più sicura e un giro di rafforzamento di protocollo/sicurezza.
SijieDeveloper
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.41.0 è una release orientata al controllo e alla sicurezza. Offre alle squadre modi più granulari per decidere chi può accedere a ciascuna app, un controllo più completo del ciclo di vita delle password e un Centro Account molto più capace per gli utenti finali. Rafforza inoltre la consegna dei codici di verifica, le regole sui nomi utente, la gestione SAML/OIDC, la protezione dai replay MFA e i percorsi di aggiornamento per il self-hosting. Ecco cosa c'è di nuovo.
Controllo degli accessi a livello di applicazione#
Ora puoi limitare l'accesso a una applicazione direttamente da Logto. Le regole di accesso possono essere mirate a utenti specifici, ruoli utente, organizzazioni o ruoli di organizzazione.
Quando un utente non corrisponde alle regole configurate, Logto blocca il flusso di accesso o autenticazione all'app con una pagina di accesso negato invece di lasciare che la richiesta prosegua. Questo rende più facile gestire il rollout delle app, l'accesso specifico per cliente, la protezione degli strumenti interni e l'accesso limitato all'organizzazione senza trasferire tutta la logica nel codice applicativo.
La Console ora supporta la scadenza della password a livello di tenant sotto Sicurezza > Politica password.
Gli amministratori possono abilitare la scadenza delle password, configurare per quanti giorni una password rimane valida ed espirare manualmente la password di un utente specifico dalla pagina dei dettagli dell’utente. Quando una password scade, l'utente deve reimpostarla tramite il metodo di recupero configurato prima di poter continuare ad accedere con la password.
SSO e passkey non sono influenzati. Gli utenti esistenti senza una data di modifica password registrata vengono gestiti senza problemi: Logto li ancora all’attivazione della politica, così godranno dell’intero periodo di validità invece di essere subito marcati come scaduti.
Il Centro Account ottiene più controlli self-service#
Il Centro Account continua ad evolversi come superficie completa di gestione identità self-service per gli utenti finali.
Questa release aggiunge gestione della sessione, revisione delle applicazioni terze connesse, gestione del profilo, caricamento avatar, caricamento avatar durante la registrazione con raccolta-profilo, controlli passkey indipendenti e una preferenza utente per la richiesta di accesso con passkey.
La pagina profilo del Centro Account, i campi personalizzati del profilo in fase di registrazione e gli endpoint di caricamento avatar sono ora disponibili fuori dalle feature gate di sviluppo.
Sono inoltre arrivati alcuni importanti fix:
Tema, piattaforma e colore del brand vengono applicati prima dell’hydration per ridurre il flash visivo.
La verifica "step-up" è limitata ai record di verifica dei permessi dell’utente.
Le identità social possono essere collegate senza password, email o verifica telefono quando l’utente non ha metodi legacy di verifica sicurezza.
La modifica del nome utente in Console ora reindirizza al Centro Account, affinché possa completarsi la verifica richiesta.
Le regole sui nomi utente a livello di tenant ora sono configurabili in Console > Esperienza di accesso > Registrazione e accesso > Opzioni avanzate.
La policy copre sensibilità a maiuscole/minuscole, lunghezza e tipi di caratteri ammessi. Viene applicata a tutte le scritture sugli username da parte dell’utente finale, inclusa la registrazione, il completamento del profilo, il Centro Account, le API Account e /me.
Il passaggio a username case-insensitive è protetto: Logto verifica se esistono nomi utente che differiscono solo per maiuscole/minuscole e blocca la modifica della policy finché non si risolvono i conflitti. Ora la claim OIDC preferred_username usa anche il campo username dell’utente se profile.preferredUsername non è impostato.
Le impostazioni dei codici di verifica vengono anch’esse spostate nella Console, sotto le impostazioni di sicurezza. Gli amministratori possono configurare la durata di scadenza e il numero massimo di tentativi per i codici di verifica.
Logto ora applica un limite di invio per destinatario a livello di sistema per le vie email/SMS di verifica e invito, incluse Experience, MFA, Account API, Management API, /me, inviti organizzazione e la legacy interaction API.
Quando un invio viene limitato, Logto emette l’evento webhook Message.RateLimited, ora selezionabile nelle impostazioni webhook della Console.
La consegna del codice di verifica a destinatari sconosciuti viene soppressa quando la registrazione è disabilitata, riducendo il rischio di enumerazione degli account.
Per i token di risorsa API di organizzazione, il customizer JWT del token di accesso ora riceve context.organization con id, name, description e customData dell’organizzazione bersaglio.
Questo rende più facile aggiungere claim per organizzazione senza dover inserire tutti i mapping organizzativi in ogni token.
Sono arrivati anche alcuni miglioramenti API:
POST /api/applications/:applicationId/roles ora è idempotente. Gli ID dei ruoli già esistenti vengono ignorati invece di restituire 422 application.role_exists.
L’endpoint ora restituisce 201 con { roleIds, addedRoleIds }, in linea con la forma dell’API di assegnazione dei ruoli utente.
La creazione di ruoli organizzativi con scope iniziali ora è transazionale, quindi eventuali ID scope non validi non lasciano ruoli creati solo parzialmente.
Questa versione include una serie di fix focalizzati su protocollo e sicurezza:
I form SAML IdP di auto-submit ora eseguono l’escape dei valori degli attributi HTML e rifiutano URL di azione non HTTP(S).
samlify è aggiornato a ^2.13.0 per un migliore escaping XML nelle assertion SAML generate.
La verifica MFA TOTP rifiuta i codici rigiocati dallo stesso o precedente counter temporale.
I body delle richieste OIDC contenenti byte nulli restituiscono ora 400 invalid_request.
I payload dei log di audit rimuovono i byte nulli prima dell’inserimento.
I controlli di blocklist sulle subaddress email non costruiscono più regex da input controllato dall’utente.
Logto Tunnel impedisce che richieste per file statici leggano al di fuori del percorso configurato di esperienza.
Inoltre, sono inclusi fix su compatibilità e storage: su Safari meno recenti e iOS 15 non si ha più crash in avvio per sintassi lookbehind regex non supportata, i connector OIDC enterprise possono ora ottenere la discovery config da provider che rifiutano la negoziazione con sola risposta JSON e i fallimenti nel trasporto asset UI su Azure Blob ora mappano su errori retryable di download storage.
È richiesta una migrazione del database per v1.41.0. Questa versione introduce alterazioni di schema per la scadenza della password, policy username, policy codice di verifica, indici per il rate dei messaggi, default Account Center e indici dei log di servizio.
Dopo l’aggiornamento, eseguire il comando di alterazione database prima di avviare la nuova versione. Vedi la guida all’aggiornamento per i dettagli.
La variabile d’ambiente CASE_SENSITIVE_USERNAME è ora deprecata. Funziona ancora come override a runtime, ma la sensibilità a maiuscole/minuscole dello username deve essere gestita per tenant tramite la nuova policy username. La variabile verrà rimossa nella prossima major release.
