Le migliori pratiche per invalidare JWT durante la modifica delle password e il logout in node.js?

Non c'è soluzione se non stai colpendo il DB. Potresti ridurre il numero di ricerche su una invece di due.

Dopo la modifica della password o logout, scrivi un numero a 128 bit generato da un CSPRNG nella riga dell'utente nella tabella utente.

Questo CSPRNG fa parte del JWT. Ad ogni accesso è necessario verificare che il numero nel JWT corrisponda al valore memorizzato nel DB. Non c'è alcun vantaggio che il MAC venga calcolato su questo valore, lo stiamo semplicemente mantenendo nel JWT, quindi tutto è in un unico posto.

In questo modo si vanifica lo scopo dell'utilizzo di JWT in primo luogo - si potrebbe anche semplicemente utilizzare un token di sessione controllato sul lato server. Il vantaggio però è che non è necessario mantenere singole sessioni lato server come una volta che un JWT scade è scaduto perché non si accettano le date di scadenza nel passato.

Un altro svantaggio è che se ci sono due sessioni contro lo stesso utente, disconnettendone uno si disconnetterebbe l'altro. Inoltre, la logica è più complicata di un sistema gestito lato server e la complessità aggiuntiva tende a ridurre la sicurezza.

Potresti utilizzare un breve tempo per la vita dei token JWT e farli rinnovare frequentemente, con un meccanismo che impedisce un rinnovo per i token JWT più vecchi. Avresti bisogno di un token di rinnovo automatico nel JWT che possa essere paragonato a qualcosa che memorizzi nel DB. Questo significa almeno che colpisci il database solo per ogni rinnovo. È possibile impostarlo su 5 minuti, il che sarebbe molto meno traffico di ogni transazione da client a web.

Tuttavia, pensateci, questa è una soluzione di manutenzione molto alta. Solo una percentuale molto piccola dei tuoi utenti chiederà effettivamente di uscire da tutti i dispositivi.

SOLUZIONE SUGGERITA:

Se volessi dire agli agenti di non fidarsi più di alcuni ID selezionati, cosa faresti? Forse potresti chiedere loro di ricontrollare con te per aggiornare i loro record per una "lista nera" una volta ogni tanto. Ora hai solo una manciata di servizi web 'stateless' che controllano ogni x minuti per un aggiornamento. Devi solo tenere una lista nera dei token JWT invalidati proattivamente che non sono ancora scaduti.

Penso che troverai questa soluzione in scala, e di solito non è necessario immediatamente scadere un token. Anche se lo facessi, potresti essere in ritardo nel fare la tua richiesta di invalidare tutti i token, quindi che differenza fa 60 secondi? Se è necessario eseguire un'azione che è così importante (lanciare le armi nucleari?) - forse dovresti chiedere al tuo utente finale di autenticarsi nuovamente in tempo reale per quello!

La migliore pratica di JWT è quella di non utilizzare il database o la cache, l'idea di JWT è il controllo di validità stateless, è possibile memorizzare l'ID utente nel payload del token e utilizzarlo quando necessario da diversi macchine senza necessità di sincronizzare un ID di sessione o simili.

Assicurati di utilizzare ID utente lunghi e casuali, quindi se un utente malintenzionato riesce a falsificare un token, rischierà un solo utente e non potrà accedere ad altri utenti, diversamente dagli ID sequenziali.

Non credo che ci sarebbe un modo per invalidare il JWT senza controllare il database ad ogni richiesta.

L'idea migliore potrebbe essere quella di rilasciare i token di accesso ai token con un breve periodo di scadenza, quindi utilizzare i token di aggiornamento se è necessario rinnovare il token di accesso.

In questo modo, sebbene non sia possibile invalidare immediatamente il token, almeno sarà utilizzabile fino alla sua scadenza. Quando viene utilizzato il token di aggiornamento, il codice di autorizzazione può decidere se emettere o meno un nuovo token di accesso.

Solo curioso però, perché dovresti invalidare il JWT solo a causa di una modifica della password? C'è qualche ragione per forzare una disconnessione a quel punto? Il JWT non include la password, quindi una password modificata non dovrebbe avere alcun impatto sul JWT.

L'unica volta in cui dovresti invalidare l'utente è se i permessi sono stati modificati o revocati.

Il logout di solito è un'azione avviata dall'utente, nel qual caso il client può semplicemente cancellare / resettare / eliminare il token JWT che ha attualmente per l'utente.