Query relativa all'architettura di autenticazione di app Web

Question

Query relativa all'architettura di autenticazione di app Web

#1 da (0 voti)
#2 da (0 voti)

2

Ho un'app Web che utilizza node.js nel backend e angulajs nel front-end.

Diciamo che ho un utente che ha la possibilità di accedere tramite più sistemi; Devo consentire più accessi.

Sto facendo uso del modulo jsonwebtoken per generare un token per un utente dopo che è stato autenticato e che viene salvato nei redis e il token viene rinviato all'utente che è stato salvato nel suo cookie.

Diciamo che ho un tempo di scadenza di 5 ore sia sul cookie che sul token (redis).

Come posso pianificare tutto?

Anche se utilizzo un set per salvare più token in redis, in realtà non posso aggiungere il tempo di scadenza su ciascun valore. E in aggiunta a tutto ciò devo tenere conto dei token di aggiornamento in modo che se un utente utilizza regolarmente il sistema, il suo token rimane attivo.

architecture authentication angularjs node.js redis

posta Gandalf the White 01.06.2016 - 14:08

fonte

2 risposte

Leggi altre domande sui tag architecture authentication angularjs node.js redis

Come separare i dati tra gruppi di utenti in Django? Devo annotare tutti i punti di ingresso nella mia biblioteca?

score 0 · Answer 1

Associa il token con l'indirizzo IP di origine della richiesta oltre al nome utente quando lo si salva in redis e durante la ricerca durante l'autenticazione di una richiesta. Ricordati di gestire il caso in cui hai un cookie ma non corrisponde al token associato all'indirizzo IP sorgente della richiesta, in tal caso l'autenticazione dovrebbe fallire.

Un'altra opzione sarebbe quella di invertire la mappatura e utilizzare il valore del token come chiave in rosso, con il nome utente e altre informazioni associate come valore. Ciò consentirebbe più accessi, ognuno con il proprio token e per cambiare gli indirizzi IP. Il problema con la possibilità di cambiare l'indirizzo IP è che chiunque possa rubare un token per una sessione di accesso valida (ad esempio dal malware sul computer della vittima) può utilizzare quel token per ignorare il processo di login fino alla scadenza del token. Ecco perché tanti siti bloccano IP i loro token di autenticazione e, se rilevano una modifica dell'indirizzo IP, richiedono la ri-autenticazione per continuare con la sessione bloccata al nuovo indirizzo IP.

score 0 · Answer 2

Il flusso del protocollo OAuth 2.0 (RFC 6749) ha affrontato questo problema dovendo distribuire token di lunga durata mentre minimizzare gli aggiornamenti al datastore. Richiede 2 token diversi, un token di accesso di breve durata che non ha bisogno di essere archiviato e un token di aggiornamento a lunga durata che può essere memorizzato (per consentire la revoca). Il flusso è raffigurato qui:

Nel tuo caso dovresti rilasciare un token di aggiornamento per utente che è firmato da una chiave segreta e quindi emettere un token di accesso che è anche firmato per ogni sessione di accesso. Il vantaggio di questo approccio è che i token di accesso di breve durata (da 5 a 10 minuti) possono essere utilizzati per la verifica stateless su ogni richiesta (poiché l'utente lo invierà come cookie o nell'intestazione). Il token di aggiornamento è longevo (5 ore) che viene archiviato in redis e viene rinnovato con una scadenza aggiornata ogni volta che un client richiede un nuovo token di accesso. Ciò garantisce che i token di aggiornamento vengano aggiornati solo quando scadono i token di accesso (in questo caso ogni 5-10 minuti massimo). Ciò fornisce una buona soluzione fornendo sicurezza (token di accesso di breve durata) ed evitando le chiamate al database (i token di aggiornamento a lunga durata devono essere aggiornati solo quando scadono i token di accesso).