Perché vengono utilizzati i token di aggiornamento

Question

Perché vengono utilizzati i token di aggiornamento

#1 da (6 voti)

8

Leggendo su JWT, vedo che è prassi comune includere un token di aggiornamento insieme al token di breve durata. Così comunemente sembra che tu abbia un token di breve durata che dura per un breve periodo di tempo, ad esempio 15 minuti, e un token di aggiornamento che rinnova questo token quando è scaduto. Dalla mia comprensione se il token di breve durata è scaduto, l'app deve verificare che il token di aggiornamento non sia stato revocato (controllare il database). In caso contrario, emettere un nuovo token di breve durata. Sto cercando di capire perché non avere un solo token di breve durata.

Supponiamo che il token jwt contenga il nome utente dell'utente che utilizza il token e scade tra 1 ora. Alla scadenza, il mio server applicazioni non può verificare questo token per verificare che sia effettivamente scaduto e che sia stato emesso da me, in tal caso controllare (all'interno del database) che questo utente possa rinnovare il proprio token e rinnovarlo. Non è essenzialmente come avere un token di aggiornamento, ma è un po 'più semplice dato che l'utente ha solo 1 token invece di 2? Non riesco a vedere il vantaggio di avere un token di aggiornamento?

authentication jwt token

posta user2924127 08.03.2016 - 01:12

fonte

1 risposta

Leggi altre domande sui tag authentication jwt token

L'implementazione di OpenPGP di YubiKey 4 Open Source? È possibile utilizzare i modelli di risoluzione CAPTCHA per rintracciare / identificare una persona?

score 6 · Answer 1

Suppongo che tu stia utilizzando una soluzione di autenticazione proprietaria, che utilizza JWT e aggiorna i token ma non ha nulla a che fare con OpenID Connect.

I token JWT sono stateless, i token di aggiornamento sono in genere statefull.

Dovresti considerare i vantaggi e gli svantaggi dei token statefull vs stateless:

I token stateless possono essere convalidati senza chiamate DB / Service aggiuntive (quindi sono più veloci / più facili da validare) ma è impossibile revocarli (nessun logout affidabile).
I token statefull possono essere revocati (logout affidabile) ma devono essere convalidati ogni volta tramite chiamata DB / Service (quindi sono più lenti).

I token JWT di lunga durata costituirebbero un rischio maggiore per la sicurezza: la finestra di attacco sarebbe lunga se il token viene rubato.

In combinazione con i token di aggiornamento, ottieni la soluzione da qualche parte nel mezzo: la convalida è veloce e il logout è più affidabile.

A seconda di dove viene utilizzato il token (client vs server), è possibile implementare l'aggiornamento automatico. Tuttavia, per tale soluzione proprietaria, è possibile utilizzare un singolo token con una cache di convalida, se necessario, a causa di motivi di prestazioni.