Flusso del token di aggiornamento JWT

Sto creando un'app mobile e sto usando JWT per l'autenticazione.

Sembra che il modo migliore per farlo sia 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 memorizzato nel database sul modello utente per l'accesso, corretto? Sembra che in questo caso dovrebbe essere crittografato
3. Avrei restituito il token di aggiornamento dopo un accesso utente e quindi il client accederà a una route separata per recuperare un token di accesso?

Supponendo che si tratti di OAuth 2.0 poiché si tratta di JWT e token di aggiornamento ...:

1. proprio come un token di accesso, in linea di principio un token di aggiornamento può essere qualsiasi cosa, comprese tutte le opzioni che descrivi; un JWT può essere utilizzato quando il server di autorizzazione vuole essere apolide o vuole applicare una sorta di semantica di "prova di possesso" al client che lo presenta; notare che un token di aggiornamento differisce da un token di accesso in quanto non viene presentato a un server risorse ma solo al server di autorizzazione che lo ha emesso in primo luogo, quindi l'ottimizzazione della convalida autonoma per i token di accesso JWT lo fa non tenere per i token di aggiornamento

2. ciò dipende dalla sicurezza / accesso al database; se il database è accessibile da altre parti / server / applicazioni / utenti, allora sì (ma il tuo chilometraggio può variare in base a dove e come memorizzi la chiave di crittografia ...)

3. un Authorization Server può emettere contemporaneamente token di accesso e token di aggiornamento, a seconda della concessione utilizzata dal client per ottenerli; la specifica contiene i dettagli e le opzioni su ciascuna delle sovvenzioni standardizzate

Di seguito sono riportati i passaggi per revocare il token di accesso JWT:

1. Quando effettui l'accesso, invia 2 token (token di accesso, token di aggiornamento) in risposta al client.
2. Il token di accesso avrà un tempo di scadenza inferiore e l'aggiornamento avrà un tempo di scadenza lungo.
3. Il client (front-end) memorizzerà il token di aggiornamento nella sua memoria locale e il token di accesso nei cookie.
4. Il client utilizzerà un token di accesso per chiamare le API. Ma quando scade, scegli il token di aggiornamento dalla memoria locale e chiama l'API del server di autenticazione per ottenere il nuovo token.
5. Il tuo server di autenticazione avrà un'API esposta che accetterà il token di aggiornamento e verificherà la sua validità e restituirà un nuovo token di accesso.
6. Una volta scaduto il token di aggiornamento, l'utente verrà disconnesso.

Per favore fatemi sapere se avete bisogno di maggiori dettagli, posso condividere anche il codice (Java + Spring boot).

Per le tue domande:

D1: È un altro JWT con meno reclami presentati con un lungo periodo di scadenza.

Q2: non sarà in un database. Il backend non verrà archiviato da nessuna parte. Decifreranno semplicemente il token con chiave privata / pubblica e lo convalideranno anche con la sua scadenza.

Q3: Sì, corretto

Basato in questa implementazione con Node.js di JWT con token di aggiornamento :

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

2) Lo implementano in un documento separato (tabella). Per me ha senso perché un utente può essere connesso 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 quel dispositivo potrebbe essere invalidato senza influire sugli altri dispositivi collegati.

3) In questa implementazione risponde al metodo di accesso con entrambi, token di accesso e token di aggiornamento. Mi sembra corretto.