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.