Vorrei sapere se quello che ho fatto finora è un modo valido per autenticare/rinnovare il token e se ci sono difetti o vulnerabilità di cui dovrei essere a conoscenza come ho provato a limitare l'interazione del database a zero. Ecco qui.Angularjs e slim framework autenticazione JWT e token refresh flow
- L'utente viene autenticato tramite normale nome utente/password o via Facebook
- Il backend PHP genera un token con una scadenza di 30 minuti e lo invia al client angularjs
- Il token JWT viene memorizzato in $ localStorage
- il token JWT viene iniettato, con l'aiuto di un intercettatore, in ogni intestazione di richiesta
- Tutti i percorsi sottili che richiedono autenticazione controllare il token inviato con l'aiuto di un middleware.
- Se il token non è valido (scaduto, è stato manomesso, non è adatto a quel particolare ruolo), Slim risponderà con un errore 401/403.
- Un servizio angolare controlla ogni minuto se il token sta per scadere
- Se il token sta per scadere (da 5 a 1 minuti rimanenti), il servizio invia il vecchio token a un altro endpoint dell'API.
- L'endpoint API verifica la validità del token e risponde con uno nuovo con una scadenza di +30 minuti.
- Il servizio di polling che ho menzionato prima sostituisce il vecchio token in $ localStorage.
- Risciacquare e ripetere.
NB: SSL sarà attuato nella produzione
Bounty assegnato a @Valdas come lui era l'unico che in realtà ha risposto
C'è un buon articolo su dove memorizzare il JWT. https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/ –
@MikaTuupola Grazie per il suggerimento. Conserverò il token in un cookie per una maggiore protezione. Ho già implementato il meccanismo anti-CSRF menzionato qui e ho dato uno sguardo al tuo middleware slim-jwt-auth. Bel lavoro! Ho fatto il mio middleware di base, ma il tuo è decisamente all'altezza. Devi provarlo. Il problema cookie/localStorage è l'unica cosa che sembra _credire_ con la mia logica? –