(generato da questo thread poiché questa è davvero una questione a sé stante e non specifica per NodeJS ecc.)
Sto implementando un server API REST con autenticazione e ho implementato con successo la gestione dei token JWT in modo che un utente possa accedere tramite un endpoint / login con nome utente / password, su cui viene generato un token JWT da un segreto del server e restituito al cliente. Il token viene quindi passato dal client al server in ogni richiesta API autenticata, su cui viene utilizzato il segreto del server per verificare il token.
Tuttavia, sto cercando di capire le migliori pratiche per esattamente come e in che misura il token dovrebbe essere convalidato, per creare un sistema veramente sicuro. Cosa dovrebbe essere coinvolto esattamente nella "convalida" del token? È sufficiente che la firma possa essere verificata utilizzando il segreto del server, o devo anche controllare il token e / o il payload del token con alcuni dati memorizzati nel server?
Un sistema di autenticazione basato su token sarà sicuro quanto il passaggio di nome utente / password in ciascuna richiesta, a condizione che sia ugualmente o più difficile ottenere un token che ottenere la password di un utente. Tuttavia, negli esempi che ho visto, le uniche informazioni richieste per produrre un token sono il nome utente e il segreto lato server. Questo non significa che supponendo per un minuto che un utente malintenzionato acquisisca la conoscenza del segreto del server, ora può produrre token per conto di qualsiasi utente, avendo così accesso non solo a un dato utente come sarebbe il fatto se fosse una password ottenuto, ma appunto a tutti gli account utente?
Questo mi porta alle domande:
1) La convalida del token JWT dovrebbe essere limitata alla verifica della firma del token stesso, basandosi sull'integrità del solo segreto del server o accompagnata da un meccanismo di convalida separato?
In alcuni casi ho visto l'uso combinato di token e sessioni del server in cui dopo il login riuscito tramite l'endpoint / login viene stabilita una sessione. Le richieste API convalidano il token e confrontano anche i dati decodificati trovati nel token con alcuni dati archiviati nella sessione. Tuttavia, utilizzare le sessioni significa utilizzare i cookie e in un certo senso vanifica lo scopo dell'utilizzo di un approccio basato su token. Può anche causare problemi a determinati client.
Si potrebbe immaginare che il server mantenga tutti i token attualmente in uso in una memcache o simile, per garantire che anche se il segreto del server viene compromesso in modo che un utente malintenzionato possa produrre token "validi", solo i token esatti che sono stati generati tramite l'endpoint / login sarebbe accettato. Questo è ragionevole o semplicemente ridondante / eccessivo?
2) Se la verifica della firma JWT è l'unico mezzo per convalidare i token, il che significa che l'integrità del segreto del server è il punto di rottura, come dovrebbero essere gestiti i segreti del server? Leggere da una variabile di ambiente e creare (randomizzato?) Una volta per stack distribuito? Rinnovato o ruotato periodicamente (e in tal caso, come gestire i token validi esistenti che sono stati creati prima della rotazione ma devono essere convalidati dopo la rotazione, forse è sufficiente se il server mantiene il segreto corrente e precedente in un dato momento) ? Qualcos'altro?
Forse sono semplicemente eccessivamente paranoico quando si tratta del rischio che il segreto del server venga compromesso, che ovviamente è un problema più generale che deve essere affrontato in tutte le situazioni crittografiche ...
RSAPrivateKey privateKey
??