La comodità che diventa trappola
I token in formato JWT sono diventati lo standard per gestire l'identità nelle applicazioni moderne, per un buon motivo: sono autosufficienti, il server non deve conservare nulla per verificarli. Ma è proprio questa la trappola. Un token autosufficiente è valido finché non scade, e il server, non conservando nulla, spesso non ha un modo semplice per dire «questo non vale più» prima della scadenza. Risultato: l'utente fa logout, ma il token che aveva continua a essere accettato fino al suo termine naturale, che a volte è lontano giorni o settimane.
I quattro punti da verificare
| Situazione | Comportamento corretto | Difetto comune |
|---|---|---|
| L'utente fa logout | La prova di identità non funziona più | Continua a funzionare fino a scadenza |
| Il token è vecchio | Scade dopo un tempo ragionevole | Non scade, o scade dopo settimane |
| L'utente cambia password | Le sessioni aperte altrove decadono | Restano tutte valide |
| Un utente viene disattivato | I suoi accessi smettono subito | La sessione aperta resta viva |
Le ultime due righe sono quelle che mordono nella pratica: il dipendente che se ne va con una sessione ancora aperta, o l'account compromesso in cui cambiare la password non basta a buttare fuori chi era entrato.
La verifica, sul vostro sistema
- 01
Accedete e catturate la prova di identità
Con un account di prova, fate login e, dagli strumenti per sviluppatori del browser, individuate il token o il cookie di sessione che accompagna le richieste.
- 02
Fate logout
Premete «esci» normalmente, come farebbe un utente.
- 03
Riprovate a usare la vecchia prova
Rifate una richiesta autenticata riutilizzando il token o il cookie di prima. Se il server la accetta ancora, il logout non ha invalidato nulla: difetto confermato.
- 04
Provate anche il cambio password
Ripetete il test dopo aver cambiato la password da un altro dispositivo: le sessioni aperte altrove dovrebbero decadere. Se restano valide, è la stessa famiglia di problema.