Quanto sono sicuri i token in scadenza e i token di aggiornamento?

Potrebbe essere che il token di accesso potrebbe finire per essere utilizzato intorno all'applicazione su semplici connessioni HTTP. Quindi, se un utente malintenzionato lo annusava, avrebbe solo un accesso a breve termine. Questo è ciò che era solito accadere sul web come standard. Il login era su HTTPS se sei stato fortunato, e il resto della sessione era su HTTP semplice, trasmettendo l'ID di sessione in chiaro.

Il token di aggiornamento viene trasmesso solo al server di autorizzazione, quindi è più semplice applicare solo HTTPS, il che significa che un utente malintenzionato non può intercettare questa connessione.

Vedi qui per ulteriori informazioni :

There is a security reason, the refresh_token is only ever exchanged with authorization server whereas the access_token is exchanged with resource servers. This mitigates the risk of a long-lived access_token leaking (query param in a log file on an insecure resource server, beta or poorly coded resource server app, JS SDK client on a non https site that puts the access_token in a cookie, etc) in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked" vs "an access token good-till-revoked without a refresh token."

Ho risposto a una domanda simile che è stata contrassegnata come duplicata di questa. Tuttavia, ritengo che la mia risposta a questa domanda fornisca un argomento più strong per come i token di aggiornamento forniscono ulteriore sicurezza. In breve, se il token di aggiornamento viene compromesso, è molto più facile rilevarlo e intraprendere le azioni appropriate, come disabilitare i token di autenticazione e i token di aggiornamento e costringere l'utente a effettuare di nuovo l'accesso con le proprie credenziali. In altre parole, le credenziali compromesse possono essere arrestate molto più rapidamente quando vengono utilizzati i token di aggiornamento.

Consideriamo che esiste un server che convalida e invia token a un client.

Cliente (invia nome utente e password) - > Server

Server (convalida le credenziali e restituisce access e refresh token) - > Client

Il client memorizza i token in modo sicuro e utilizza il token di accesso per le ulteriori chiamate API effettuate al server (fino alla scadenza del token di accesso). Una volta scaduto il token di accesso, il client potrebbe ricevere un codice HTTP 401 (non autorizzato) dal server e si rende conto che il token di accesso non è più valido.

Il client utilizza quindi il token di aggiornamento e ottiene i nuovi token di accesso e aggiornamento dal server.

Effetti di un token di accesso compromesso : l'utente malintenzionato potrà accedere ai dati fino alla scadenza del token di accesso.

Effetti di un token di aggiornamento compromesso : l'utente malintenzionato può ottenere un nuovo token di accesso e aggiornamento che può anche invalidare l'accesso della vittima. Quando la vittima tenta di ottenere un nuovo token di accesso con il proprio token di aggiornamento, fallirà perché il proprio token di aggiornamento è già stato utilizzato. La vittima dovrebbe effettuare di nuovo l'accesso utilizzando le proprie credenziali per riemettere i token e invalidare i token rubati dell'attaccante.