Gestione della scadenza del token jwt

Question

Gestione della scadenza del token jwt

#1 da (1 voti)

2

Ho un backend nodejs basato su koajs per la mia app personale / hobby. Ho implementato la gestione delle sessioni con i token jwt. Ora il client ottiene il suo token dopo una corretta autenticazione di login, quindi il mio client angularjs memorizza il token da qualche parte (attualmente in sessionStorage ma per questa domanda non ci interessa la memorizzazione). Ho due domande

Quando devo aggiornare il record dell'utente che il jwt rappresenta, ad esempio, l'utente ha attivato 2FA, quindi gli ho chiesto di fornire il suo numero di telefono e vorrei impostare questo numero di telefono nel record dell'utente. Attualmente, dopo una verifica riuscita sul numero di telefono, chiamo il mio backend per aggiornare il record dell'utente e creo un nuovo token JWT con il record utente aggiornato (escludo informazioni sensibili dal token jwt come il hash pwd e altri .., ma Mi piacerebbe includere il numero di telefono per l'utilizzo lato client). Quindi, fondamentalmente la domanda è, è giusto creare un nuovo token quando alcune delle credenziali cambiano e aggiornano il token lato client esistente con questo nuovo token? Non dovrei mai creare un altro token, solo per crearne uno solo dopo aver autenticato con successo? Come aggiornare quindi il payload nel token?
Come devo gestire i token jwt scaduti? Nella mia mente ho 3 (possibili) scenari:
1. Il jwt è impostato su vita breve, diciamo 15 minuti. Se il server di backend risponde con un token ivalidale 401 non autenticato (presumo che questo sia il comportamento predefinito di koa-jwt), allora disconnetto automaticamente il mio client e richiedo la ri-autenticazione. Ma ho anche creato un middleware complementare che è l'ultimo della catena sul back-end per ricreare il token con una scadenza aggiornata e il client sostituirà anche il token esistente con quello aggiornato. Quindi, se l'utente è attivo e utilizza l'applicazione ogni chiamata API protetta, in caso di successo, creerebbe un nuovo token per sostituire il vecchio token.
2. Il jwt è impostato per durare a lungo, diciamo 1 settimana, e se scade, accetto nuovamente la re-autenticazione dal client.
3. Copia link . Qui, quando si crea il token jwt dopo un'autenticazione corretta, inviamo un access_token e un refresh_token. Quando il token di accesso è scaduto e il server risponde con 'token non valido' HTTP 401 (default koa-jwt), il client invia il refresh_token al backed per richiedere un nuovo access_token (opzionalmente un nuovo refresh_token). In questo caso, non capisco appieno come viene verificato il refresh_token rispetto al vecchio access_token per fornire un nuovo token? O perché abbiamo bisogno di avere un refresh_token?

Fondamentalmente ho solo bisogno di consigli generici sugli argomenti superiori (aggiornamenti jwt e scadenza jwt). Grazie

node.js jwt

posta Jim-Y 03.10.2016 - 08:50

fonte

1 risposta

Leggi altre domande sui tag node.js jwt

In che modo la "probabilità di verifica" è inversamente proporzionale alla "falsa percentuale di accettazione"? Come posso proteggere le chiavi per i dati memorizzati in un'applicazione web Python contro la violazione del server?

score 1 · Answer 1

" è corretto creare un nuovo token quando alcune credenziali cambiano "

Assolutamente. Generalmente i token dovrebbero essere di breve durata, quindi crearne uno nuovo non è un problema.
La risposta qui in parte dipende da come stai gestendo il problema dell'attacco di replay man-in-the-middle con JWT. Se non stai facendo nulla, i tuoi token devono essere di breve durata ma potresti non volere che i tuoi clienti debbano riconnettersi costantemente. È qui che entra in gioco il meccanismo di aggiornamento. Offre una funzionalità intermedia opzionale per aggiornare i token senza un accesso completo.

Se gestisci il problema MITM, avrai una sicurezza aggiuntiva sul lato server per validare i token utente. In tal caso, puoi permetterti di avere token più longevi.

In entrambi i casi, se gli utenti modificano i loro dettagli di sicurezza in qualche modo, sembra ragionevole invalidare il token e richiedere un altro accesso. Ma dipende interamente da te. È necessario comprendere il valore degli utenti, delle loro sessioni e dei rischi. Quando lo capisci, puoi decidere in modo ragionevole quanti rischi vuoi trasportare e come meglio mitigare il rischio che non vuoi portare.