La mia idea è di usare i token crittografati - dove su autenticazione (con username e password), backend crittograferebbe user_id, timestamp e SHA-256 su questi, base 64 lo codifica e ritorna al client come token di accesso. In questo modo posso eliminare la necessità di un archivio di token persistente.
Questo è simile allo schema descritto in questo articolo (ci sono alcune differenze però).
La logica che vorrei avere è che quando il token viene utilizzato costantemente (ovvero l'intervallo più lungo tra le successive chiamate API non è più lungo di N), l'utente non dovrebbe essere richiesto per la riautenticazione .
Il problema è che la validità del token crittografato non può essere estesa, poiché la modifica del timestamp indica il valore delle modifiche del token .
Riesco a vedere le seguenti soluzioni:
1) Ogni volta che il token viene convalidato, emettere un nuovo token e tornare al client. Ad ogni richiesta, il client dimenticherà il token precedente e invece ne memorizzerà uno nuovo.
- + risolve il problema
- + la logica sul client è piuttosto semplice
- - per un utente, più token sarebbero validi allo stesso tempo
2) Implementare un endpoint API che accetta un token scaduto e in cambio emetterà un nuovo token. Questo endpoint avrebbe un valore configurabile M, quindi se il token è scaduto da più di M, il nuovo token non verrebbe emesso.
- + risolve il problema
- + per un utente, solo un token sarebbe valido allo stesso tempo
- La logica - sul client è un po 'più complicata: è necessario aggiornare il token.
C'è un'altra soluzione, basata su token crittografati? (So che possiamo risolvere il problema con token regolari e persistenti)