Autenticazione senza stato con JWT: il token di aggiornamento non è stateless

10

Nella mia attuale architettura, il mio backend invia un JWT al client (mobile). La ragione principale per optare per un JWT è l'autenticazione stateless, cioè il server non ha bisogno di memorizzare i dati nella sessione / database, il che significa meno problemi di overhead e scalabilità.
Una strategia comune è quella di accedere all'utente e restituire il JWT di breve durata (circa 15 minuti - come ho letto), insieme a un token di aggiornamento che l'utente memorizza nel client. Il token di aggiornamento non scade mai e può essere revocato. Lo scopo sarebbe evitare di inviare un JWT di lunga durata sul filo troppe volte e aggiornare il JWT solo quando scaduto; quando un attaccante ottiene il possesso del token di breve durata, la finestra del tempo di attacco è breve.

Il problema è che questa storia sembra piena di buchi quando ci penso. Per favore aiutami a chiarire.

  1. Un tempo di scadenza di 15 minuti significherebbe che alcuni utenti potrebbero anche inviare un token di aggiornamento sul filo 10 volte al giorno. Potrebbe essere una frequenza tanto alta quanto alcuni utenti farebbero richieste con un token di accesso regolare e di breve durata. Pertanto l'argomento del token di aggiornamento sembra discutibile.
  2. Se metti in dubbio l'SSL, allora non so perché così tante aziende usano l'autenticazione di base. Per utilizzare JWT con token di aggiornamento, probabilmente dovresti comunque utilizzare HTTPS.
  3. Qual è il vantaggio di JWT se è necessario memorizzare un token di aggiornamento nella sessione / database per emettere un nuovo jwt sul client. In questo caso, il token di aggiornamento agirà come una sorta di password (anche se mi rendo conto che non è esattamente la stessa) che viene memorizzata nel back-end. Ciò rende il flusso di autenticazione essenzialmente statico e sembra eliminare il vantaggio dell'utilizzo del JWT. Inoltre, con un breve periodo di scadenza di 15 minuti, significa che si ha un sovraccarico eccessivo, che è necessario ottenere un token di accesso aggiornato quasi ogni volta che si controlla il telefono se è presente un intervallo di 30 minuti. Non solo c'è il sovraccarico per controllare il token di aggiornamento memorizzato, inoltre è necessario verificare se il token di aggiornamento è nella lista nera, il che significa un altro overhead delle prestazioni. (Modifica: l'ultimo controllo può essere rimosso semplicemente rimuovendo il token di aggiornamento dal db una volta revocato).
  4. Un token di aggiornamento richiede più roundtrip del server:
    • 401 viene restituito quando il token di accesso è scaduto (server delle risorse).
    • È necessario richiedere un nuovo token di accesso sul server di autenticazione
    • La richiesta al server delle risorse deve essere riavviata.

Qualcuno può spiegarmi cosa mi manca qui?

    
posta Trace 11.06.2017 - 00:04
fonte

2 risposte

8

Una delle principali critiche ai token di sessione senza stato è la mancanza di un logout sicuro. Avere un token di accesso / aggiornamento separato consente un compromesso. È possibile ridurre notevolmente la quantità di accesso al database, pur avendo una funzione di disconnessione sicura con un ritardo di 15 minuti.

Il design non fa nulla per proteggere contro il dirottamento di sessione, ad esempio l'acquisizione dannosa del token. Basta usare SSL, è onnipresente in questi giorni.

Puoi ridurre la quantità di round trip con un po 'di attenzione. Molte librerie HTTP client ti consentono di eseguire l'autenticazione proattiva, evitando il viaggio di andata e ritorno per ottenere un 401.

Sono d'accordo sul fatto che non è un design particolarmente sensibile. La maggior parte dei siti Web è pesante in ogni caso, quindi controllare un token su ogni richiesta non è molto più oneroso. E mentre il concetto di base di token di accesso / aggiornamento è sicuro, temo che la complessità aggiuntiva inviti a difetti di implementazione.

    
risposta data 20.06.2017 - 20:09
fonte
1

A meno che non ci siano altre risposte a questa domanda, la mia soluzione attuale è che si tratta di valutare i compromessi dei rischi per la sicurezza rispetto alle prestazioni.

La mia considerazione principale è di aumentare la finestra temporale del token di accesso jwt "di breve durata" di 15 minuti a un giorno.
Questo dato che HTTPS è richiesto e che le richieste vengono fatte solo internamente, cioè i token non viaggiano nel dominio incrociato.

Questo significa che in termini di prestazioni, l'aggiornamento dei token avviene solo una volta al giorno. In teoria, SSL dovrebbe fornire una sicurezza sufficiente nel mio caso; un singolo giorno di finestra di attacco è semplicemente una misura di sicurezza in cima a qualcosa che non dovrebbe accadere in primo luogo.

Sebbene i token di aggiornamento rendano essenzialmente lo stato del processo di autenticazione, questo può essere accettabile poiché la maggior parte delle richieste (in questo caso in un giorno) al server delle risorse si verificano ancora utilizzando il jwt.

    
risposta data 11.06.2017 - 02:16
fonte

Leggi altre domande sui tag