È un refresh token nessesary con HTTPS

1

Comprendo appieno i vantaggi del token di aggiornamento nel caso in cui il token di accesso venga compromesso.

Invio il token di accesso JWT al server solo tramite HTTPS per un'applicazione mobile e un'applicazione web che richiede un accesso permanente. Quindi credo che il token di accesso non possa essere compromesso a meno che il dispositivo dell'utente non sia nelle mani dell'attaccante. Anche in questo caso se il dispositivo dell'utente è con le mani dell'aggressore, entrambi i token di aggiornamento e il token di accesso sarebbero compromessi.

C'è un altro modo per compromettere il token di accesso? Se NO, nel mio caso, è necessario avere un sistema di token di aggiornamento?

UPDATE 1: utilizzo solo un singolo server. Nessun server di autenticazione e server delle risorse separati.

    
posta Aswin Kumar K P 05.07.2017 - 14:34
fonte

1 risposta

2

Una delle principali differenze tra i token di accesso e i token di aggiornamento è chi può vederli.

Il token di accesso viene distribuito dal server di autorizzazione e viene quindi utilizzato dal client per accedere alle risorse del proprietario della risorsa. Il token di accesso è visto sia dal server di autorizzazione, sia dal client e dal server di risorse.

Il token di aggiornamento viene distribuito dal server di autorizzazione e viene visualizzato solo dal client e dal server di autorizzazione. Il server di risorse non vede mai il token di aggiornamento.

Quindi, il token di accesso è più vulnerabile; è visto da più parti. Un'implementazione trascurata sul Resource Server potrebbe portare alla fuoriuscita del token di accesso, mentre il token di aggiornamento sarebbe comunque sicuro.

Credito: ho ricevuto aiuto da questa risposta di Overflow dello stack scrivendo questo.
Uno scenario menzionato è che il token di accesso potrebbe essere inviato come parametro di query e quindi finire in un file di registro. Il token di accesso è stato protetto da HTTPS durante il transito, ma ora si trova nel file di registro sul server di risorse. Le persone che non hanno il diritto di conoscere il token di accesso potrebbero avere il diritto di vedere il file di registro. Ad esempio, gli studenti che hanno un lavoro estivo come supporto tecnico.

Ciò che è importante, tuttavia, non è cercare di inventare uno scenario specifico in cui le cose potrebbero andare storte. Ciò che è importante è rendersi conto che che il token di accesso potrebbe perdere con il token di aggiornamento ancora sicuro. È una forma di programmazione difensiva - essere preparati per il caso che ci sia una vulnerabilità nel Resource Server.

Poiché nella situazione indicata il server di autorizzazione e il server di risorse sono una singola applicazione, la maggior parte degli scenari in cui il token di accesso è compromesso avrà anche un compromesso del token di aggiornamento.

Come nota a margine, ho lavorato a uno scenario simile. Abbiamo usato Identity Server come server di autorizzazione. È stato integrato nell'applicazione. Se questa applicazione trapelasse, vorrei prima cercare la parte del Resource Server. Identity Server è stato creato da esperti di sicurezza e, essendo Open Source, è stato esaminato da molti. La parte del Resource Server di quella particolare applicazione era proprietaria. Si consiglia di guardare anche Identity Server per la propria applicazione.

    
risposta data 05.07.2017 - 14:55
fonte

Leggi altre domande sui tag