JWT Aggiorna token in modo esponenziale?

Question

JWT Aggiorna token in modo esponenziale?

#1 da (1 voti)
#2 da (0 voti)

2

Ecco come faccio il mio token di aggiornamento JWT:

Un token controlla la validità ogni volta che viene effettuata una richiesta. Se non è scaduto, consenti l'accesso.

Se è scaduto, chiama un'altra funzione chiamata RefreshToken per assegnare un nuovo token all'utente.

Ok questo meccanismo è abbastanza buono tranne che ogni token scaduto (di quell'utente, a condizione che sia valido) può attivare la creazione di un nuovo token nuovo.

Ad esempio
La scadenza è di 15 minuti.
Il token A è stato creato.
Il token A richiede un nuovo token di aggiornamento dopo 1 ora.
Viene rilasciato un nuovo token, denominato Token B.
Dopo 15 minuti, il token B è scaduto.
Ora, il token A e il token B possono chiedere un nuovo token.
Non creerebbe la possibilità di emettere un token in modo esponenziale?
Solo da 1 gettone.
E il token può emettere un altro token e così via. Un token scaduto 15 anni fa può rilasciare un nuovo token di aggiornamento oggi anche se è stato usato un po 'di tempo in 15 anni fa e aveva emesso un altro token.

Ora ogni token rilasciato può creare un altro token. Posso solo consentire il token A - > Token B - > Token E senza memorizzare il token scaduto nel database?

L'ordine dell'alfabeto token ha la precedenza

security authentication

posta momokjaaaaa 14.05.2016 - 05:52

fonte

2 risposte

Leggi altre domande sui tag security authentication

Estrarre casi di test end-to-end su più pagine Come posso scoprire la latenza di rete nel servizio di riposo

score 1 · Answer 1

Nei sistemi di autenticazione basati su token, uno schema comune è quello di distinguere tra token di breve durata e token di lunga durata . I token di breve durata vengono utilizzati per tutte le chiamate API e scadono rapidamente. I token a vita lunga sono solo utilizzati per il recupero di token a vita breve e la loro esposizione ad altri ambienti è ridotta al minimo.

Quando un utente accede per la prima volta, ottiene un token longevo che è memorizzato nel browser in qualche modo e mai usato tranne quando ha bisogno di un nuovo token a breve durata. I token di breve durata vengono utilizzati per tutte le chiamate. Il sistema può tenere un registro di tutti i token di lunga durata emessi per consentire agli amministratori di forzare la scadenza di token di lunga durata. Questo è fondamentalmente il modo in cui funzionano le funzioni "ricordami su questo dispositivo". Puoi andare oltre usando il token longevo per generare più token a vita breve, ciascuno valido per una finestra diversa di 15 minuti della prossima ora circa. I token long life consentono anche la separazione delle preoccupazioni, perché tutti possono verificare la validità dei token di breve durata, ma solo un determinato servizio di autenticazione può essere autorizzato a generare nuovi token. I client invierebbero sempre i loro token long-life a quel servizio di autenticazione, riducendo al minimo la possibilità che gli intercettatori della rete rubino il token.

Tuttavia, se i token di breve durata scaduti possono essere aggiornati con solo il token, in realtà non scadono. A chi importa se un token scade dopo quindici minuti se tutto ciò che devi fare è chiamare un servizio rinfrescante con solo il token e ne ottieni uno nuovo? Distrugge la sicurezza della scadenza dei token, il punto è che dopo la scadenza delle credenziali hai bisogno di una forma più strong di autenticazione per riemettere le credenziali.

score 0 · Answer 2

Una delle idee dietro al sistema OAuth è che il fornitore di risorse può verificare la validità del token di autenticazione e leggere le sue affermazioni, ma NON rilasciarti un token stesso. Per questo è necessario tornare al provider di autenticazione e richiederne uno con il tuo nome utente / password o il tuo token di aggiornamento.

se i tuoi fornitori di risorse emettono automaticamente un nuovo token quando ricevono un token di autenticazione scaduto, in effetti non hai nessuna scadenza.

Inoltre, il fornitore di risorse 2 dovrà affidarsi al fornitore di risorse 1 anziché al servizio di autenticazione