JWT refresh token flow

Question

Sto costruendo un'app mobile e sto utilizzando JWT per l'autenticazione.

Sembra che il modo migliore per farlo è quello di accoppiare il token di accesso JWT con un token di aggiornamento in modo da poter scadere il token di accesso tutte le volte che voglio.

1. Che aspetto ha un token di aggiornamento? È una stringa casuale? Quella stringa è crittografata? È un altro JWT?
2. Il token di aggiornamento verrebbe archiviato nel database sul modello utente per l'accesso, corretto? Sembra che dovrebbe essere crittografato in questo caso
3. Avrei inviato il token di aggiornamento dopo un accesso utente e poi il client ha accesso a una route separata per recuperare un token di accesso?

Answer 1

Partendo dal presupposto che si tratta di OAuth 2.0 in quanto si tratta di JWTs e aggiornare gettoni ...:

1. proprio come un token di accesso, in linea di principio un token di aggiornamento può essere qualsiasi cosa tra cui tutte le opzioni che descrivi; una JWT può essere utilizzata quando il server di autorizzazione vuole essere senza stato o vuole applicare una sorta di semantica di "prova di possesso" al client che la presenta; si noti che un token di aggiornamento differisce da un token di accesso in quanto non viene presentato a un server di risorse ma solo al server di autorizzazione che lo ha rilasciato in primo luogo, quindi l'ottimizzazione di convalida autonoma per i token di accesso come JWT avviene non valido per i token di aggiornamento

2. che dipende dalla sicurezza/accesso del database; se il database è accessibile ad altre parti/server/applicazioni/utenti, allora sì (ma il tuo chilometraggio può variare con dove e come si memorizza la chiave di crittografia ...)

3. un server di autorizzazione può rilasciare entrambi i token di accesso e aggiornare i token allo stesso tempo, a seconda della concessione che viene utilizzata dal client per ottenerli; spec contiene i dettagli e le opzioni su ciascuna delle sovvenzioni standardizzati

Answer 2

relativo a questo implementation with Node.js of JWT with refresh token:

1) In questo caso si usa un uid e non è un JWT. Quando aggiornano il token, inviano il token di aggiornamento e l'utente. Se lo si implementa come JWT, non è necessario inviare l'utente, perché all'interno del JWT.

2) Lo implementano in un documento separato (tabella). Ha senso per me perché un utente può essere registrato in diverse applicazioni client e potrebbe avere un token di aggiornamento per app. Se l'utente perde un dispositivo con un'app installata, il token di aggiornamento di tale dispositivo potrebbe essere invalidato senza influire sugli altri dispositivi connessi.

3) In questa implementazione la risposta al metodo di accesso con entrambi, token di accesso e token di aggiornamento. Mi sembra giusto.