È sicuro utilizzare lo stesso token come token di aggiornamento e token di accesso?

5

Per quanto comprendo in OAuth c'è un token di aggiornamento e c'è un token di accesso. Il token di accesso non può essere revocato ma di breve durata e al prossimo accesso di aggiornamento non ci sarà alcun token di accesso se revocato. Ho una semplice applicazione in cui rilascio i miei token e consumo tutto in un'unica applicazione (sia mobile che web, ma stessa API), quindi non ho bisogno di alcun OAuth o OpenIdConnect complesso per le parti 3D. Voglio utilizzare questo schema con un solo token per semplicità, ma voglio aggiornarlo anche per motivi di prestazioni (non controllare la revoca su ogni chiamata):

  1. Un client fornisce un nome utente e una password a un endpoint speciale e riceve un JWT che è firmato ma non crittografato (che è abbastanza buono per quanto ho capito, l'utente può leggere ma non forgiare). Io uso JwtSecurityTokenHandler in .NET per emettere il token senza i server Oauth o OpenIdConenct per farlo. Il token è firmato usando RSA SHA 256 con certificato che ho creato io stesso. Il token è di breve durata, ad es. 1 ora.
  2. Tutte le chiamate API vengono modificate con l'autenticazione Bearer e leggo il token sul server e verifica la firma e la scadenza (nient'altro come Audience, ecc.). Il server si fiderà di questo token e non controllerà la revoca.
  3. Se il server rileva che un token è scaduto, restituirà circa 40x per consentire al client di aggiornare il token. (Il cliente può effettuare una pre-verifica della data di scadenza stessa poiché il token non è crittografato per salvare alcune chiamate al server).
  4. Se il token è scaduto, il client chiamerà l'aggiornamento e passerà lo stesso token ad esso. La differenza sarà che questa volta viene verificato lo stato di revoca (ho una semplice revoca di tutti i token per i criteri utente, non per token). Verificherò il timestamp aggiuntivo del problema iniziale che non viene modificato con gli aggiornamenti e verificherò che è maggiore del timestamp dell'utente che è impostato ad es. quando un utente cambia password. Il risultato è un altro token dello stesso tipo con lo stesso timestamp iniziale e il tempo di scadenza di 1 ora in più. Se revocato, l'utente dovrà relogon.

Ho davvero bisogno di aggiornare solo a causa di considerazioni sulle prestazioni, ma mi chiedo forse mi manca qualcosa e c'è davvero un problema di sicurezza o forse altri problemi con questo flusso semplificato con un solo token?

    
posta Ilya Chernomordik 25.01.2016 - 10:50
fonte

1 risposta

2

Se hai il controllo sia del client che del server e puoi garantire che entrambi i token siano sempre trasmessi in modo sicuro, non c'è alcun inconveniente nell'usare lo stesso token per entrambi.

Normalmente, il token di aggiornamento è il token critico da proteggere, poiché consente un accesso indefinito all'applicazione. È anche più facile controllare quali trasporti vengono trasmessi. Tuttavia, nel tuo caso, se puoi applicare la stessa sicurezza al token di accesso, non vi è alcun rischio in più di essere lo stesso.

Anche vedi questa risposta .

    
risposta data 26.01.2016 - 10:07
fonte

Leggi altre domande sui tag