Autenticazione JWT e schema di autorizzazione

Naviga le tue risposte
4

Stavo passando per i documenti di Oauth2 e pensavo che fosse una sorta di sicurezza permissiva, quindi ho provato a implementare token JWT con uno schema speciale come nell'immagine per un'app mobile che comunica con un'API Web.

Note: non mi piaceva l'idea dei token di aggiornamento di Oauth2 in quanto potrebbero essere rubati e consentire l'uso parallelo (da parte di utenti legittimi e malintenzionati) a meno che non si implementa il rilevamento dei furti ruotandoli (aggiornando il token di aggiornamento su ogni richiesta) in questo caso perché usarli del tutto?

Come funziona il flusso di autenticazione:

  1. Un utente che accede con le credenziali ottiene un jwt di 20 minuti di durata.
  2. Alla scadenza il jwt viene aggiornato premendo il db controllando se è nella lista nera (relogin) e se non controlla se è stato usato per generare un nuovo token.
  3. Se non è mai stato utilizzato per l'aggiornamento, viene accettato e utilizzato per rilasciare un token di accesso di basso livello.
  4. Se il token è stato usato in precedenza, o aveva client + dispositivo + utente diversi da quello genitore offre un controllo delle credenziali (password o codice della schermata di blocco)
  5. Se superata, questo controllo emette un nuovo token di primo grado che esegue la blacklist di tutti i suoi genitori e figli sul db, è come un nuovo primo accesso utente.
  6. Se lockscreen fallisce, all'utente viene presentata una schermata di accesso.

Le domande sono:

  1. Quali sono i possibili buchi di sicurezza? (Ho trovato due casi d'uso: il token di accesso rubato dura 20 minuti lo stesso numero dei token Oauth. Nessun guadagno in questo caso. E token dormiente rubato: l'utente non ha effettuato il login per 7 giorni, il token viene rubato e utilizzato fino a quando l'utente non esegue nuovamente l'accesso o la catena di token rivoltata dopo 3 mesi di persistenza - la nostra politica - e questo furto ha piccole probabilità poiché il token deve essere intercettato all'ultima richiesta fatta dall'utente sull'app, più sottile del furto di un token di aggiornamento Oauth2
  2. Quali sono i problemi di esperienza utente che un utente malintenzionato può causare nell'app mentre si trova in questo schema?
posta Asma Hakim 12.05.2016 - 23:28
fonte

1 risposta

3

Come dice @jpodwys nel suo commento, HTTPS è un transito sicuro. Mi sembra molto improbabile che un utente malintenzionato possa rubare un token di aggiornamento OAuth2 e non rubare altre informazioni importanti. Cioè, quando hai i token rubati sulle connessioni HTTPS, sei già stato pwnato e il gioco è finito. OAuth2 è un protocollo ben testato che ha molte implementazioni testate in molte lingue. Sospetto strongmente che sarà più sicuro di qualsiasi cosa tu decida di progettare e implementare da solo. In generale, rotolare il tuo è un errore. Vedi tutte queste risposte per i motivi per cui.

In risposta alla tua domanda sul perché esistono i token di aggiornamento, esistono per consentire all'utente di revocare l'autorizzazione, non di gestire un token di aggiornamento rubato (in quanto ciò non avviene mai in modo efficace). Considera il caso in cui un utente concede l'accesso e successivamente, improvvisamente, lo revoca. Si desidera ridurre al minimo il ritardo tra la revoca che si verifica alla revoca che ha effetto. Un modo per portare il ritardo a (quasi) zero è verificare con il fornitore di servizi ad ogni chiamata. Ma il controllo con SP su ogni richiesta non è performante. Invece, si consente di utilizzare il token di accesso per un periodo di tempo limitato e forzarlo a rinnovarlo di tanto in tanto. Ciò significa che se l'utente revoca l'autorizzazione, avrà effetto in un tempo non superiore alla durata del token di accesso.

    
risposta data 13.05.2016 - 03:45
fonte

Leggi altre domande sui tag

Esiste una valida tecnica di prevenzione lato server contro CSRF supportato da PHP? Perché il proxy BlueCoat trasmette la comunicazione HTTPS ai siti Google?