Postmortem: cambio inaspettato di JWT `iss`

Sommario#

Il 18-03-2024, un aggiornamento che ha modificato il comportamento dell'emittente JWT in Logto Cloud ha interrotto i flussi di autenticazione per gli utenti con domini personalizzati e validazione iss. La correzione ha richiesto a questi utenti di aggiornare la loro logica di validazione.

• Utenti interessati: utenti con domini personalizzati abilitati e che eseguono la validazione iss.
• Gravità: Critico, interrompe la validazione iss nei flussi di autenticazione.

Causa principale#

L'aggiornamento ha modificato il campo iss per adattarsi al dominio richiesto, interrompendo le validazioni esistenti che si aspettavano l'emittente predefinito precedente.

Cronologia#

• 18-03-2024 10:00 (UTC): implementati aggiornamenti, cambiando il comportamento di iss.
• 18-03-2024 23:30 (UTC): ricevuta la prima segnalazione di un utente sulla rottura del comportamento esistente.
• 19-03-2024 12:00 (UTC): confermata la questione e avviata l'indagine.
• 19-03-2024 14:00 (UTC): identificata la causa principale e l'impatto.
• 20-03-2024 20:00 (UTC): preparata l'email per gli utenti interessati.
• 20-03-2024 06:00 (UTC): inviate email a tutti gli utenti interessati.

Analisi dell'impatto#

Dettagli del rilascio#

Logto Cloud supporta i domini personalizzati per l'autenticazione, gli sviluppatori che hanno tenant abilitati con domini personalizzati possono impostare l'endpoint sul dominio personalizzato nelle SDK, quindi l'utente finale utilizzerà questo endpoint per iniziare il processo di autenticazione e ottenere i token. Alcuni token sono nella forma di JWT, che include un campo iss che indica l'emittente di questo token. In precedenza, anche quando veniva utilizzato un endpoint di dominio personalizzato per richiedere un token di accesso, l'emittente rimaneva il nostro dominio standard ([tenant-id].logto.app).

Ma il dominio dell'emittente dovrebbe essere lo stesso dell'endpoint richiesto. Quindi abbiamo rilasciato un aggiornamento per risolvere questo problema, e ora il campo iss rifletterà automaticamente il dominio utilizzato nella richiesta.

Per coloro che stanno già utilizzando un dominio personalizzato per concedere token e hanno implementato la validazione del campo iss nel server delle risorse, questo potrebbe essere un cambiamento dirompente. Il controllo di autenticazione esistente fallirà a causa del cambio di emittente. Per risolvere questo, gli sviluppatori devono modificare il codice di validazione, sostituire l'emittente previsto con il nuovo con dominio personalizzato.

Non siamo riusciti a considerare completamente l'impatto sulle validazioni iss esistenti, di conseguenza, questo rilascio è diventato un cambiamento dirompente senza notifica preventiva.

Risoluzione#

Utenti interessati notificati via email, consigliando di aggiornare la loro validazione iss per adattarla al dominio richiesto.

Rollback?#

Il cambiamento è una correzione necessaria per il campo emittente, e alcuni utenti potrebbero essersi già adattati al nuovo comportamento. Un rollback causerebbe confusione e incoerenza.

Lezioni apprese#

• Le modifiche al codice che influenzano l'autenticazione principale devono avere l'approvazione del team oltre alle revisioni regolari.
• I test automatici dovrebbero coprire più casi, specialmente su scenari specifici del cloud.

Misure correttive e preventive#

• Aggiungi test di integrazione: Aggiungi casi di test per coprire lo scenario in questo incidente.
• Progetti di monitoraggio delle funzionalità: Oltre a Logto Cloud, crea i nostri progetti collaterali e integrali profondamente con Logto per rilevare potenziali problemi prima dei rilasci.