Logto v1.42.0 introduce file di verifica del dominio personalizzati, allowlist e-mail con pattern wildcard, link magici per il reset della password, un webhook Grant.LimitExceeded e un aggiornamento del livello di protocollo con node-oidc-provider v9, Koa 3 e protezione SSRF attivata di default.
SimengDeveloper
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.42.0 è una release incentrata su domini e protocolli. Offre ai team un modo per dimostrare la proprietà del dominio senza dover gestire un altro host, un controllo più preciso su quali email possano entrare in un tenant e un percorso di reset password più fluido per gli utenti finali. Sotto il cofano, sposta Logto su node-oidc-provider v9 e Koa 3, attivando la protezione SSRF per le richieste OIDC in uscita di default. Ecco cosa c’è di nuovo.
I servizi di terze parti spesso verificano la proprietà di un dominio chiedendoti di servire un piccolo file in un percorso fisso. Fino ad ora ciò richiedeva di eseguire un host separato accanto al tuo dominio personalizzato Logto.
Ora puoi allegare file di verifica a un dominio personalizzato attivo da Console > Impostazioni tenant > Domini. Ogni file ha:
Un percorso che è o un nome file a livello root con estensione (ad esempio /verify.txt) o un percorso sotto /.well-known/.
Un content type text/plain o application/json. I contenuti JSON sono validati al salvataggio.
Contenuto fino a 16 KB.
Si possono configurare fino a 10 file per dominio e i percorsi devono essere unici. Logto serve richieste GET e HEAD esatte con il tipo di contenuto configurato e rafforza la risposta. Le route esistenti di Logto hanno sempre la precedenza su un file di verifica allo stesso percorso, quindi un file mal configurato non potrà mai oscurare un endpoint reale. L'esperienza della Console è localizzata in tutte le lingue supportate.
Poiché Logto non si occupa del contenuto dei file, questa funzionalità è compatibile con qualsiasi schema di verifica di provider senza modellare comportamenti specifici del provider.
Regole di accesso email: allowlist e pattern wildcard#
La policy di blocklist email si espande in un set più completo di regole di accesso email, configurabili da Console > Sicurezza > Blocklist email.
Allowlist e-mail personalizzata. Configura una lista di indirizzi email, domini o pattern con wildcard. Quando la allowlist è impostata, solo le email corrispondenti sono accettate per nuove registrazioni e per nuovi collegamenti email — sia durante la registrazione sia negli aggiornamenti dell'email dell'account.
Pattern wildcard. Sia la allowlist che la blocklist accettano sia pattern di indirizzi che di domini con wildcard, ad esempio foo*@example.com, *@example.com e @*.example.com, oltre agli indirizzi ([email protected]) e domini (@example.com) esatti.
Avvisi di conflitto. La Console avvisa se una voce in allowlist corrisponde anche a una regola di blocco, se una voce in allowlist usa il simbolo più mentre è bloccato il subaddressing e-mail e se le regole combinate bloccherebbero tutte le nuove email.
La logica di matching e validazione è condivisa tramite helper riutilizzabili in @logto/core-kit, così le stesse regole si applicano dovunque una email entri in un tenant.
L’app Experience ora supporta flussi di reset password che verificano i magic link one-time-token direttamente dalla pagina di atterraggio del reset password, oltre ai codici di verifica.
Quando i grant OIDC vengono annullati perché un’applicazione ha superato il massimo limite consentito di grant, Logto ora invia un evento webhook Grant.LimitExceeded, selezionabile nelle impostazioni webhook della Console come qualsiasi altro evento.
Il payload riporta userId, applicationId, revokedGrantIds, maxAllowedGrants e preRevocationActiveGrantCount. L’inoltro è fire-and-forget: i fallimenti vengono registrati come voci di log di audit TriggerHook.Grant.LimitExceeded e non bloccano mai la risposta di autenticazione.
La modifica più importante riguarda una correzione di sicurezza nella revoca dei token.
Revocando un token di accesso opaco ora vengono revocati anche tutti i token sotto lo stesso grant, inclusi i refresh token. Nella v8, il refresh token rimaneva utilizzabile dopo la revoca e poteva continuare a richiedere nuovi access token.
Altri aggiornamenti di protocollo in v9:
L'endpoint di revoca ora rifiuta i JWT access token con unsupported_token_type, invece di restituire un successo senza revocare nulla come avveniva in v8.
L’endpoint delle informazioni del server di autorizzazione RFC 8414 è disponibile su /oidc/.well-known/oauth-authorization-server.
L'asserzione ridondante at_hash viene rimossa dagli ID token emessi dall’endpoint dei token.
Gli ID token non includono più l’header opzionale typ: "JWT". OpenID Connect definisce gli ID token come JWT e non richiede ai client di verificarlo.
Azione richiesta per la verifica personalizzata degli ID token. Nessuna azione è richiesta se usi un SDK ufficiale Logto. Se la tua integrazione esegue una verifica custom degli ID token, aggiornala per permettere che l’asserzione at_hash possa non essere presente e che anche l’header typ: "JWT" possa non essere presente.
Logto ora gira su Koa 3, la release attivamente mantenuta che riceve per prima gli aggiornamenti di sicurezza di Koa. Non sono attesi cambiamenti di comportamento: tutti gli endpoint, i flussi OIDC e le risposte API si comportano come prima.
I segreti delle applicazioni interne non vengono più esposti tramite le API di gestione.
La policy di blocklist e-mail non viene più restituita nelle risposte pubbliche di esperienza di sign-in.
Per recuperare token di accesso di provider terzi tramite l’Account API ora serve lo scope utente identities, come per tutti gli altri endpoint di identità social ed enterprise SSO.
I codici di verifica API Account non vengono più inviati a indirizzi email bloccati.
La validazione di e-mail e dominio ora esige valori completi ed etichette di dominio più severe.
Quando un flusso di registrazione social o SSO è rifiutato dalle regole di accesso e-mail, l’errore ora riporta l’utente alla pagina di login Logto invece di indirizzarlo all’identity provider esterno.
MFA ora viene attivato automaticamente dopo che l’utente ha collegato un fattore tramite le API Account.
La creazione di un nuovo connector email o SMS esegue inserimento e pulizia dei connector vecchi in una sola transazione. Prima, un crash tra i due statement poteva lasciare connettori duplicati.
Le credenziali del cluster Redis ora vengono decodificate in percentuale, così le connessioni funzionano anche se username o password contengono caratteri riservati dalle URL.
TLS ora è correttamente abilitato per connessioni Redis cluster che usano il protocollo rediss.
jose v6: I connector Apple, Google, OAuth e OIDC ora usano jose 6, che si basa su Web Crypto API invece del modulo crypto di Node. La firma dei token e la verifica degli ID token funzionano come prima.
GitLab: Rimossa la dipendenza jose non usata, così ora installare il connector non scarica più pacchetti inutili.
Aliyun SMS: I numeri di telefono di Hong Kong ora sono considerati numeri esteri.
Aliyun SMS autenticazione MAS: Ora la firma viene inserita come testo libero invece che selezionata da un menu, così continua a funzionare anche se Aliyun cambia nuovamente le firme.
Azione richiesta — Protezione SSRF provider OIDC. La sicurezza delle richieste in uscita è rafforzata e la protezione SSRF ora è abilitata per default. I deployment self-hosted che devono raggiungere endpoint di relying-party affidati sulle reti private devono settare OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true prima di avviare Logto; altrimenti lasciare la variabile non settata.
Migrazione database richiesta. Questa release apporta modifiche schema per la gestione dei file di verifica dominio personalizzato, oltre a indici e tabelle interni. Dopo l’aggiornamento, eseguire il comando di alterazione database (npm run alteration deploy nell’immagine @logto/cli/core oppure logto db alteration deploy) prima di avviare la nuova versione. Consulta la guida all’aggiornamento per i dettagli.
Verifica ID token personalizzata. Vedi la sezione node-oidc-provider v9 qui sopra per i cambiamenti su at_hash e l’header typ.
