La sezione 4.2 della bozza del protocollo OAuth 2.0 indica che un server di autorizzazione può restituire sia un access_token(che viene utilizzato per autenticarsi con una risorsa) sia un refresh_token, che viene utilizzato esclusivamente per creare un nuovo access_token:
https://tools.ietf.org/html/rfc6749#section-4.2
Perché entrambi? Perché non fare l' access_tokenultimo fino a quando refresh_tokennon hai un refresh_token?
Risposte:
L'idea dei token di aggiornamento è che se un token di accesso è compromesso, poiché è di breve durata, l'attaccante ha una finestra limitata in cui abusarne.
I token di aggiornamento, se compromessi, sono inutili perché l'attaccante richiede l'ID client e il segreto oltre al token di aggiornamento per ottenere un token di accesso.
Detto questo , poiché ogni chiamata al server di autorizzazione e al server di risorse viene eseguita su SSL, inclusi l'ID client e il segreto originali quando richiedono i token di accesso / aggiornamento, non sono sicuro di come sia il token di accesso " compromettibile "rispetto al token di aggiornamento di lunga durata e alla combinazione clientid / secret.
Questo ovviamente è diverso dalle implementazioni in cui non si controllano sia i server di autorizzazione che quelli delle risorse.
Ecco un buon thread che parla degli usi dei token di aggiornamento: OAuth Archives .
Una citazione di cui sopra, parlando degli scopi di sicurezza del token di aggiornamento:
Aggiorna token ... mitiga il rischio di perdite di access_token di lunga durata (query param in un file di registro su un server di risorse non sicuro, beta o app server di risorse scarsamente codificate, client JS SDK su un sito non https che inserisce access_token in un cookie, ecc.)
Il link alla discussione, fornito da Catchdave, ha un altro punto valido (originale, dead link) fatto da Dick Hardt, che credo valga la pena essere menzionato qui oltre a quanto scritto sopra:
Il mio ricordo dei token di aggiornamento era per la sicurezza e la revoca. <...>
revoca: se il token di accesso è autonomo, è possibile revocare l'autorizzazione non emettendo nuovi token di accesso. Non è necessario che una risorsa richieda al server di autorizzazione di verificare se il token di accesso è valido. Ciò semplifica la convalida del token di accesso e semplifica il ridimensionamento e il supporto di più server di autorizzazione. C'è una finestra temporale in cui un token di accesso è valido, ma l'autorizzazione viene revocata.
In effetti, nella situazione in cui Resource Server e Authorization Server sono la stessa entità e in cui la connessione tra l'utente e uno di essi è (di solito) ugualmente sicura, non ha molto senso mantenere il token di aggiornamento separato dal token di accesso.
Sebbene, come menzionato nella citazione, un altro ruolo dei token di aggiornamento sia quello di garantire che il token di accesso possa essere revocato in qualsiasi momento dall'utente (tramite l'interfaccia web nei loro profili, ad esempio) mantenendo il sistema scalabile allo stesso tempo .
In genere, i token possono essere identificatori casuali che puntano al record specifico nel database del server o possono contenere tutte le informazioni in sé (certamente, queste informazioni devono essere firmate, con MAC , ad esempio ).
Come dovrebbe funzionare il sistema con token di accesso di lunga durata
Il server consente al Cliente di accedere ai dati dell'utente all'interno di un set predefinito di ambiti emettendo un token. Poiché vogliamo mantenere il token revocabile, dobbiamo archiviare nel database il token insieme al flag "revocato" impostato o non impostato (altrimenti, come lo faresti con il token autonomo?) Il database può contenere fino alen(users) x len(registered clients) x len(scopes combination) record . Ogni richiesta API quindi deve colpire il database. Sebbene sia abbastanza banale eseguire query su tale database eseguendo O (1), il singolo punto di errore stesso può avere un impatto negativo sulla scalabilità e sulle prestazioni del sistema.
Come dovrebbe funzionare il sistema con token di aggiornamento di lunga durata e token di accesso di breve durata
Qui vengono emesse due chiavi: token di aggiornamento casuale con il record corrispondente nel database e token di accesso indipendente firmato, contenente tra l'altro il campo data / ora di scadenza.
Poiché il token di accesso è autonomo, non è necessario accedere al database per verificarne la validità. Tutto quello che dobbiamo fare è decodificare il token e convalidare la firma e il timestamp.
Tuttavia, dobbiamo comunque mantenere il database dei token di aggiornamento, ma il numero di richieste a questo database è generalmente definito dalla durata del token di accesso (maggiore è la durata, minore è la velocità di accesso).
Per revocare l'accesso del Cliente da un determinato Utente, dovremmo contrassegnare il token di aggiornamento corrispondente come "revocato" (o rimuoverlo completamente) e interrompere l'emissione di nuovi token di accesso. È ovvio, tuttavia, che esiste una finestra durante la quale il token di aggiornamento è stato revocato, ma il suo token di accesso potrebbe essere ancora valido.
compromessi
I token di aggiornamento eliminano parzialmente lo SPoF (Single Point of Failure) del database dei token di accesso, ma presentano alcuni ovvi inconvenienti.
La finestra". Un intervallo di tempo tra gli eventi "l'utente revoca l'accesso" e "l'accesso è garantito per essere revocato".
La complicazione della logica del cliente.
senza token di aggiornamento
con token di aggiornamento
Spero che questa risposta abbia un senso e aiuti qualcuno a prendere una decisione più ponderata. Vorrei anche notare che alcuni noti provider OAuth2, tra cui github e foursquare, adottano il protocollo senza token di aggiornamento e sembrano soddisfatti.
Nonostante tutte le ottime risposte di cui sopra, io come studente di sicurezza e programmatore che in precedenza ha lavorato su eBay quando ho dato un'occhiata alla protezione dell'acquirente e alla frode, posso dire che separare il token di accesso e aggiornare il token ha il suo miglior equilibrio tra molestare l'utente con un nome utente frequente / inserimento password e mantenendo l'autorità a disposizione per revocare l'accesso a potenziali abusi del servizio.
Pensa a uno scenario come questo. Concedi all'utente un token di accesso di 3600 secondi e aggiorna il token molto più a lungo di un giorno.
L'utente è un buon utente, è a casa e accede / spegne il tuo sito web acquistando e cercando sul suo iPhone. Il suo indirizzo IP non cambia e ha un carico molto basso sul server. Come 3-5 richieste di pagina ogni minuto. Al termine dei 3600 secondi sul token di accesso, ne richiede uno nuovo con il token di aggiornamento. Sul lato server, controlliamo la sua cronologia delle attività e l'indirizzo IP, pensiamo che sia un essere umano e si comporti da solo. Gli garantiamo un nuovo token di accesso per continuare a utilizzare il nostro servizio. L'utente non dovrà inserire nuovamente nome utente / password fino a quando non avrà raggiunto un giorno la durata del token di aggiornamento stesso.
L'utente è un utente negligente . Vive a New York, negli Stati Uniti, ha chiuso il suo programma antivirus ed è stato violato da un hacker in Polonia . Quando l'hacker ha ottenuto il token di accesso e il token di aggiornamento, cerca di impersonare l'utente e utilizzare il nostro servizio. Ma dopo la scadenza del token di accesso di breve durata, quando l'hacker tenta di aggiornare il token di accesso, sul server abbiamo notato un drammatico cambiamento dell'IP nella cronologia del comportamento degli utenti (ehi, questo ragazzo accede negli Stati Uniti e ora aggiorna l'accesso in Polonia dopo solo 3600 ???). Terminiamo il processo di aggiornamento, invalidiamo il token di aggiornamento stesso e chiediamo di inserire nuovamente nome utente / password.
L'utente è un utente malintenzionato . Ha intenzione di abusare del nostro servizio chiamando 1000 volte la nostra API ogni minuto usando un robot. Può farlo fino a 3600 secondi dopo, quando tenta di aggiornare il token di accesso, abbiamo notato il suo comportamento e pensiamo che potrebbe non essere un essere umano. Rifiutiamo e terminiamo il processo di aggiornamento e gli chiediamo di inserire nuovamente nome utente / password. Ciò potrebbe potenzialmente interrompere il flusso automatico del suo robot. Almeno lo mette a disagio.
Puoi vedere che il token di aggiornamento ha funzionato perfettamente quando proviamo a bilanciare il nostro lavoro, l'esperienza dell'utente e il potenziale rischio di un token rubato. Il tuo watch dog sul lato server può controllare più della modifica dell'IP, la frequenza delle chiamate API per determinare se l'utente deve essere un buon utente o meno.
Un'altra parola è che puoi anche provare a limitare il controllo dei danni del token rubato / abuso del servizio implementando su ogni chiamata API il watch watch IP di base o qualsiasi altra misura. Ma questo è costoso in quanto è necessario leggere e scrivere record sull'utente e rallentare la risposta del server.
Nessuna di queste risposte arriva alla ragione principale per cui esistono token di aggiornamento. Ovviamente, puoi sempre ottenere una nuova coppia di accesso-token / refresh-token inviando le tue credenziali client al server di autenticazione, ecco come le ottieni in primo luogo.
Pertanto, l'unico scopo del token di aggiornamento è limitare l'uso delle credenziali del client inviate via cavo al servizio di autenticazione. Più breve è il ttl del token di accesso, più spesso le credenziali del client dovranno essere utilizzate per ottenere un nuovo token di accesso, e quindi maggiori sono le opportunità che gli aggressori devono compromettere le credenziali del client (anche se questo può essere super difficile comunque se la crittografia asimmetrica viene utilizzata per inviarli). Pertanto, se si dispone di un token di aggiornamento monouso, è possibile ridurre arbitrariamente le dimensioni dei token di accesso senza compromettere le credenziali del client.
Per chiarire un po 'di confusione devi capire i ruoli del segreto client e della password utente , che sono molto diversi.
Il client è un'app / sito Web / programma / ..., supportato da un server, che desidera autenticare un utente utilizzando un servizio di autenticazione di terze parti. Il segreto del client è una stringa (casuale) nota sia a questo client che al server di autenticazione. Utilizzando questo segreto il client può identificarsi con il server di autenticazione, ricevendo l' autorizzazione a richiedere token di accesso.
Per ottenere il token di accesso iniziale e il token di aggiornamento, è necessario:
Per ottenere un token di accesso aggiornato, tuttavia il client utilizza le seguenti informazioni:
Ciò mostra chiaramente la differenza: durante l'aggiornamento, il client riceve l'autorizzazione per aggiornare i token di accesso utilizzando il suo segreto client e può quindi autenticare nuovamente l'utente utilizzando il token di aggiornamento anziché l'ID utente + la password. Questo impedisce efficacemente all'utente di dover reinserire la propria password.
Ciò dimostra anche che perdere un token di aggiornamento non è un problema perché l'ID client e il segreto non sono noti. Dimostra anche che è fondamentale mantenere l'ID client e il segreto del client .
Questa risposta è di Justin Richer tramite la mailing list standard di OAuth 2. Questo è pubblicato con il suo permesso.
La durata di un token di aggiornamento dipende dal server di autorizzazione (AS): possono scadere, essere revocati, ecc. La differenza tra un token di aggiornamento e un token di accesso è il pubblico: il token di aggiornamento ritorna solo al server di autorizzazione, il token di accesso va al server delle risorse (RS).
Inoltre, ottenere un token di accesso non significa che l'utente abbia effettuato l'accesso. In effetti, l'utente potrebbe non essere più lì, che è in realtà il caso d'uso previsto del token di aggiornamento. L'aggiornamento del token di accesso ti darà accesso a un'API per conto dell'utente, non ti dirà se l'utente è lì.
OpenID Connect non ti fornisce solo informazioni utente da un token di accesso, ma ti dà anche un token ID. Questo è un dato separato che è diretto al client stesso, non all'AS o alla RS. In OIDC, dovresti considerare qualcuno che in realtà ha "effettuato l'accesso" dal protocollo se riesci a ottenere un nuovo token ID. Non è probabile che l'aggiornamento sia sufficiente.
Per ulteriori informazioni, leggere http://oauth.net/articles/authentication/
I clienti possono essere compromessi in molti modi. Ad esempio un telefono cellulare può essere clonato. La scadenza di un token di accesso significa che il client è costretto a riautenticare il server delle autorizzazioni. Durante la riautenticazione, il server di autorizzazione può verificare altre caratteristiche (IOW esegue la gestione adattiva degli accessi).
I token di aggiornamento consentono solo una nuova autenticazione del client, dove una nuova autorizzazione forza una finestra di dialogo con l'utente che molti hanno indicato che preferirebbero non fare.
I token di aggiornamento si adattano essenzialmente allo stesso posto in cui i normali siti Web potrebbero scegliere di riautenticare periodicamente gli utenti dopo circa un'ora (ad es. Sito bancario). Al momento non è molto utilizzato poiché la maggior parte dei siti Web social non esegue nuovamente l'autenticazione degli utenti Web, quindi perché dovrebbero autenticare nuovamente un client?
Perché non fare solo durare il token di accesso fino a quando il token di aggiornamento non ha un token di aggiornamento?
Oltre alle ottime risposte fornite da altre persone, c'è un altro motivo per cui utilizzare i token di aggiornamento e che ha a che fare con le affermazioni.
Ogni token contiene attestazioni che possono includere qualsiasi cosa dal nome degli utenti, i loro ruoli o il provider che ha creato il reclamo. Quando un token viene aggiornato, queste affermazioni vengono aggiornate.
Se aggiorniamo i token più spesso, stiamo ovviamente mettendo a dura prova i nostri servizi di identità, ma stiamo ottenendo reclami più accurati e aggiornati.
Per semplificare ulteriormente la risposta di BT: utilizzare i token di aggiornamento quando in genere non si desidera che l'utente debba digitare nuovamente le credenziali, ma si desidera comunque che il potere sia in grado di revocare le autorizzazioni (revocando il token di aggiornamento)
Non è possibile revocare un token di accesso, ma solo un token di aggiornamento.
Questa risposta è stata messa insieme dall'aiuto di due sviluppatori senior (John Brayton e David Jennes).
Il motivo principale per utilizzare un token di aggiornamento è ridurre la superficie di attacco.
Supponiamo che non ci sia un tasto di aggiornamento e passiamo attraverso questo esempio:
Un edificio ha 80 porte. Tutte le porte sono aperte con la stessa chiave. La chiave cambia ogni 30 minuti. Alla fine dei 30 minuti devo dare la vecchia chiave al keymaker e ottenere una nuova chiave.
Se sono l'hacker e ottengo la tua chiave, alla fine dei 30 minuti la spedirò al keymaker e riceverò una nuova chiave. Potrò continuamente aprire tutte le porte indipendentemente dal cambio di chiave.
Domanda: Durante i 30 minuti, quante opportunità di hacking ho avuto contro la chiave? Ho avuto 80 opportunità di hacking, ogni volta che hai usato la chiave (pensa a questo come fare una richiesta di rete e passare il token di accesso per identificarti). Quindi questa è una superficie di attacco 80X.
Ora passiamo allo stesso esempio, ma questa volta supponiamo che ci sia un tasto di aggiornamento.
Un edificio ha 80 porte. Tutte le porte sono aperte con la stessa chiave. La chiave cambia ogni 30 minuti. Per ottenere una nuova chiave, non riesco a passare il vecchio token di accesso. Devo solo passare la chiave di aggiornamento.
Se sono l'hacker e ottengo la tua chiave, posso usarla per 30 minuti, ma alla fine dei 30 minuti l'invio al keymaker non ha alcun valore. In tal caso, il keymaker direbbe semplicemente questo token di aggiornamento errato. Per poter estendere il mio hack dovrei hackerare il corriere al keymaker. Il corriere ha una chiave distinta (pensala come un token di aggiornamento).
Domanda: Durante i 30 minuti, quante opportunità di hacking ho avuto contro il tasto di aggiornamento? 80? No. Ho avuto solo 1 opportunità di hacking. Durante il tempo il corriere comunica con il keymaker. Quindi questa è una superficie d'attacco 1X. Ho avuto 80 opportunità di hacking contro la chiave, ma non vanno bene dopo 30 minuti.
Un server verificherebbe un token di accesso in base alle credenziali e alla firma (in genere) di un JWT.
Una perdita del token di accesso è errata, ma una volta scaduta non è più utile a un utente malintenzionato. Una perdita di token di aggiornamento è molto peggio, ma presumibilmente è meno probabile. (Penso che ci sia spazio per chiedersi se la probabilità di una perdita di token di aggiornamento sia molto inferiore a quella di una perdita di token di accesso, ma questa è l'idea.)
Il punto è che il token di accesso viene aggiunto a ogni richiesta effettuata, mentre un token di aggiornamento viene utilizzato solo durante il flusso di aggiornamento. Meno possibilità di un MITM di vedere il token
La frequenza aiuta un attaccante. Possibili perdite di cuore, come potenziali difetti di sicurezza in SSL, potenziali difetti di sicurezza nel client e potenziali difetti di sicurezza nel server.
Inoltre, se il server delle autorizzazioni è separato dal server delle applicazioni che elabora altre richieste client, quel server delle applicazioni non vedrà mai i token di aggiornamento. Vedrà solo token di accesso che non dureranno a lungo.
La compartimentazione è buona per la sicurezza.
Ultimo ma non meno importante vedere questa risposta fantastica
Di quale token di aggiornamento NON si tratta?
La possibilità di aggiornare / revocare il livello di accesso tramite i token di aggiornamento è un sottoprodotto della scelta di utilizzare i token di aggiornamento, altrimenti un token di accesso autonomo potrebbe essere revocato o avere il suo livello di accesso modificato quando scade e gli utenti ottengono un nuovo token
Supponi di fare l' access_tokenultimo lunghissimo, e non ce l'hai refresh_token, quindi un giorno l'hacker lo capiràaccess_token e può accedere a tutte le risorse protette!
Ma se lo hai refresh_token, il access_tokentempo di vita è breve, quindi l'hacker è difficile da hackerare access_tokenperché non sarà valido dopo un breve periodo di tempo.
Access_tokenpuò essere recuperato solo utilizzando non solo refresh_tokenma anche da client_ideclient_secret , che l'hacker non ha.
Mentre il token di aggiornamento viene mantenuto dal server di autorizzazione. Il token di accesso è autonomo, quindi il server delle risorse può verificarlo senza memorizzarlo, risparmiando così lo sforzo di recupero in caso di convalida. Un altro punto mancante nella discussione è da rfc6749 # page-55
"Ad esempio, il server di autorizzazione potrebbe utilizzare la rotazione del token di aggiornamento in cui viene emesso un nuovo token di aggiornamento con ogni risposta di aggiornamento del token di accesso. Il token di aggiornamento precedente viene invalidato ma conservato dal server di autorizzazione. Se un token di aggiornamento viene compromesso e successivamente utilizzato da sia l'attaccante che il cliente legittimo, uno di loro presenterà un token di aggiornamento non valido, che informerà il server di autorizzazione della violazione. "
Penso che il punto centrale dell'utilizzo del token di aggiornamento sia che anche se l'attaccante riesce in qualche modo a ottenere il token di aggiornamento, l'ID client e la combinazione segreta. Con le chiamate successive per ottenere un nuovo token di accesso dall'attaccante può essere tracciato nel caso in cui ogni richiesta di aggiornamento comporti un nuovo token di accesso e un token di aggiornamento.
A Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Consideriamo un sistema in cui ogni utente è collegato a uno o più ruoli e ogni ruolo è collegato a uno o più privilegi di accesso. Queste informazioni possono essere memorizzate nella cache per migliorare le prestazioni dell'API. Tuttavia, potrebbero esserci dei cambiamenti nell'utente e nelle configurazioni dei ruoli (ad esempio, potrebbe essere concesso un nuovo accesso o potrebbe essere revocato l'accesso corrente) e questi dovrebbero riflettersi nella cache.
A tale scopo possiamo utilizzare i token di accesso e aggiornamento. Quando viene richiamata un'API con token di accesso, il server delle risorse controlla i diritti di accesso alla cache. SE ci sono nuove concessioni di accesso, non si riflette immediatamente. Una volta scaduto il token di accesso (diciamo tra 30 minuti) e il client utilizza il token di aggiornamento per generare un nuovo token di accesso, la cache può essere aggiornata con le informazioni aggiornate sull'accesso utente dal DB.
In altre parole, possiamo spostare le costose operazioni da ogni chiamata API utilizzando i token di accesso all'evento di generazione di token di accesso utilizzando il token di aggiornamento.
Innanzitutto, il client esegue l'autenticazione con il server di autorizzazione fornendo la concessione di autorizzazione.
Quindi, il client richiede il server delle risorse per la risorsa protetta fornendo il token di accesso.
Il server delle risorse convalida il token di accesso e fornisce la risorsa protetta.
Il client effettua la richiesta di risorsa protetta al server delle risorse concedendo il token di accesso, dove il server delle risorse lo convalida e serve la richiesta, se valida. Questo passaggio continua a ripetersi fino alla scadenza del token di accesso.
Se il token di accesso scade, il client esegue l'autenticazione con il server di autorizzazione e richiede un nuovo token di accesso fornendo un token di aggiornamento. Se il token di accesso non è valido, il server delle risorse invia al client la risposta di errore del token non valida.
Il client esegue l'autenticazione con il server di autorizzazione concedendo il token di aggiornamento.
Il server di autorizzazione quindi convalida il token di aggiornamento autenticando il client ed emette un nuovo token di accesso, se valido.
access token + refresh token?