2016-05-12 28 views
5

Stavo passando per i documenti Oauth2 e pensavo che fosse una specie di sicurezza permissiva, così ho provato a implementare token JWT con uno schema speciale come nell'immagine per un'app mobile che comunica con un'API web.Autenticazione e autorizzazione app con JWT

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

Come il flusso di autenticazione funziona:

  1. un utente accede con le credenziali ottiene un JWT di 20 minuti tutta la vita.
  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 emettere un token di accesso di basso livello.
  4. Se il token è stato usato prima, o ha avuto diversi client + dispositivo + utente rispetto al suo genitore offrono un controllo delle credenziali (password o il codice lockscreen)
  5. se approvata, questo controllo emette un nuovo primo token grado che blacklist tutti i suoi genitori e i bambini sul db, è come un nuovo primo accesso utente.
  6. Se lockscreen fallisce l'utente viene presentato con schermata di login.

Le domande sono:

  1. Quali sono le possibili falle 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 al login dell'utente o la catena del token rivitalizzata dopo 3 mesi di persistenza - la nostra politica - e questo furto ha piccole probabilità poiché il token deve essere intercettato all'ultima richiesta dell'utente sull'app, più sottile del furto di un token di aggiornamento Oauth2
  2. Che cos'è l'esperienza utente problemi che un attaker può causare sull'app mentre si trova su questo schema?

jwt auth flow

risposta

0

OAuth2 refresh tokens non sono destinate ad essere utilizzato dai client mobili. L'utilizzo dei token di aggiornamento richiede le credenziali del cliente, che non possono essere archiviate in modo sicuro in un'applicazione mobile.

I token di aggiornamento vengono utilizzati da client riservati (ad esempio applicazioni Web lato server). Spesso vengono rinnovati quando vengono utilizzati (il server restituisce un nuovo accesso e un nuovo token di aggiornamento). A differenza dei token di accesso, il token di aggiornamento viene inviato solo al server di autorizzazione, non al server di risorse (API).

Riguardo al flusso di autenticazione. Il passaggio 2 è il collegamento debole IMO. Consenti al client di utilizzare un token scaduto per generare un nuovo token di accesso. Quindi, se trovo il tuo telefono e accedo al dispositivo, mi consentirà di ottenere un nuovo token di accesso e di impersonare te.

È possibile forzare il client ad aggiornare il token ogni 15 minuti, ma poi è necessario definire cosa succede se l'app viene chiusa o il dispositivo viene spento? Va bene autenticare nuovamente l'utente?

+0

Il tuo caso d'uso: il telefono rubato farà sì che l'utente malintenzionato si impadronisca di tutte le app di accesso persistenti e ti impersoni: facebook, google .... Quindi questo buco è comune, ecco perché c'è la revoca dei dispositivi su questi cruscotti delle app. –

Problemi correlati