Perché OAuth v2 hanno entrambi Access e Refresh Gettoni?

StackOverflow https://stackoverflow.com/questions/3487991

Domanda

Sezione 4.2 del progetto di OAuth protocollo 2.0 indica che un server di autorizzazione può restituire sia un access_token (che viene utilizzato per l'autenticazione se stessi con una risorsa), così come un refresh_token, che viene utilizzato esclusivamente per creare un nuovo access_token:

https://tools.ietf.org/html/rfc6749#section-4.2

Perché avere entrambi? Perché non basta fare l'ultima access_token fino a quando il refresh_token e non hanno un refresh_token?

È stato utile?

Soluzione

L'idea di token di aggiornamento è che se un token di accesso è compromesso, perché è di breve durata, l'attaccante ha una finestra limitato per abusarne.

Aggiorna token, se compromessa, sono inutili perché l'attaccante richiede l'ID client e segreta oltre al token di aggiornamento al fine di ottenere un token di accesso.

Dopo aver detto che , perché ogni chiamata sia al server di autorizzazione e il server di risorse è fatto su SSL - tra cui l'id client originale e segreta quando richiedono i accesso / gettoni di aggiornamento - sono incerto su come il token di accesso è più "compromisable" rispetto al token di aggiornamento e clientid / combinazione segreta di lunga durata.

Questo naturalmente è diversa per le implementazioni in cui non controllare sia i server di autorizzazione e di risorse.

Ecco un buon filo parlando di uso di token di aggiornamento: OAuth Archives .

Una citazione da quanto sopra, parlando dei motivi di sicurezza del token di aggiornamento:

  

Aggiorna gettoni ... mitiga il rischio di una prospettiva a lungo vissuto access_token perdite (query param in un file di log su un server risorsa insicuro, beta o scarsamente codificato app server di risorsa, il client JS SDK su un sito non HTTPS che mette il access_token in un cookie, ecc)

Altri suggerimenti

Il link alla discussione, fornito da Catchdave, ha un altro valido punto (originale, link morto) fatta da Dick Hardt, che credo sia la pena di essere menzionato qui in aggiunta a ciò che è stato scritto sopra:

  

Il mio ricordo di gettoni di aggiornamento è stato per la sicurezza e la revoca.   <...>

     

revoca: se il token di accesso è autonomo, l'autorizzazione può essere revocata evitando di rilasciare nuovi token di accesso. Una risorsa non ha bisogno di interrogare il server di autorizzazione per vedere se il token di accesso è l'accesso token di convalida valid.This semplifica e rende più facile da scala e di supportare più server di autorizzazione. C'è una finestra di tempo in cui un token di accesso è valido, ma l'autorizzazione è revocata.

In effetti, nella situazione in cui Server Resource e autorizzazione Server è la stessa entità, e dove la connessione tra utente e uno di loro è (di solito) altrettanto sicuro, non c'è molto senso mantenere token di aggiornamento separato dal token di accesso .

Anche se, come accennato nella citazione, un altro ruolo di gettoni di aggiornamento è quello di garantire il token di accesso può essere revocata in qualsiasi momento dall'utente (tramite l'interfaccia web nei loro profili, ad esempio) mantenendo la scalabilità del sistema in allo stesso tempo.

In generale, i token può essere sia identificatori casuali che puntano al record specifico nel database del server, oppure possono contenere tutte le informazioni in loro stessi (di certo, queste informazioni devono essere firmati, con MAC , per esempio).

Come il sistema con token di accesso di lunga durata dovrebbe funzionare

Il server permette al Cliente di ottenere l'accesso ai dati dell'utente all'interno di un insieme predefinito di scopi mediante l'emissione di un token. Come vogliamo mantenere la revoca di token, dobbiamo memorizzare nel database del token insieme con il flag "revocata" essere insieme o disinserire (in caso contrario, come è possibile farlo con l'auto-contenute gettone?) Database può contenere fino a len(users) x len(registered clients) x len(scopes combination) record. Ogni richiesta API quindi deve colpire il database. Anche se è abbastanza banale per fare domande a tale banca dati che svolgono O (1), il singolo punto di errore stesso può avere un impatto negativo sulla scalabilità e le prestazioni del sistema.

Come funziona il sistema di aggiornamento di lunga durata token e token di accesso di breve durata dovrebbe funzionare

Qui emettiamo due chiavi: aggiornamento casuale token con il record corrispondente nel database, e firmato token di accesso autonomo, che contiene tra gli altri il campo di scadenza timestamp

.

Mentre il token di accesso è a sé stante, non abbiamo a colpire la base di dati a tutti di verificare la sua validità. Tutto ciò che dobbiamo fare è quello di decodificare il token e per convalidare la firma e il timestamp.

Tuttavia, abbiamo ancora per mantenere il database di token di aggiornamento, ma il numero di richieste per questo database è generalmente definito dalla durata del token di accesso (la più lunga è la durata della vita, minore è il tasso di accesso).

Al fine di revocare l'accesso di client da un determinato utente, si dovrebbe segnare l'aggiornamento corrispondente token come "revocata" (o rimuovere completamente) e cessare di emettere nuovi token di accesso. E 'ovvio però che c'è una finestra durante la quale il token di aggiornamento è stato revocato, ma il suo token di accesso può essere ancora valido.

Compromessi

Aggiorna gettoni in parte eliminare lo SPOF (Single Point of Failure) di database di Access Token, ma hanno alcuni svantaggi evidenti.

  1. La "finestra". Un lasso di tempo tra gli eventi "utente revoca l'accesso" e "l'accesso è garantito per essere revocata".

  2. Il complicazione della logica client.

    senza token di aggiornamento

    • ordine di trasmissione API con token di accesso
    • se token di accesso non è valido, non riescono e chiedere all'utente di riautenticare

    token di aggiornamento

    • ordine di trasmissione API con token di accesso
    • Se token di accesso non è valido, provare ad aggiornarlo tramite token di aggiornamento
    • se aggiornamento richiesta passa, aggiornare il token di accesso e ri-inviare la richiesta API iniziale
    • Se aggiornamento richiesta fallisce, chiedere all'utente di riautenticare

Spero che questa risposta non ha senso e aiuta qualcuno a prendere la decisione più riflessivo. Mi piacerebbe anche notare che alcuni ben noti fornitori di OAuth2, tra cui github e Foursquare adottare il protocollo senza gettoni di aggiornamento, e sembrano soddisfatti di questo.

Nonostante tutte le grandi risposte sopra, come studente maestro di sicurezza e programmatore che ha già lavorato a eBay quando ho preso uno sguardo in Protezione acquirenti e la frode, può dire di accesso separato token e token di aggiornamento ha il suo miglior equilibrio tra molesto utente di frequente nome utente di input / password e mantenere l'autorità in mano per revocare l'accesso al potenziale abuso del vostro servizio.

Pensate a uno scenario come questo. Si emette utente di un token di accesso di 3600 secondi e token di aggiornamento molto più a lungo come un giorno.

  1. L'utente è un bene utente, lui è a casa e ottiene on / off carrello sito web e la ricerca sul suo iPhone. Il suo indirizzo IP non cambiare e avere un carico molto basso sul vostro server. Come 3-5 Page richieste ogni minuto. Quando i suoi 3600 secondi sul token di accesso è finita, si richiede una nuova con il token di aggiornamento. Noi, sul lato server, controllare la cronologia delle attività e l'indirizzo IP, pensiamo che è un essere umano e si comporta. Noi lo concediamo un nuovo token di accesso di continuare ad utilizzare il nostro servizio. L'utente non avrà bisogno di inserire nuovamente il nome utente / password fino a quando non ha raggiunto uno giorno la durata della vita dei token di aggiornamento per sé.

  2. L'utente è un incurante utente. Vive in New York, Stati Uniti d'America e ha ottenuto il suo arresto virus programma ed è stato violato da un hacker in Polonia . Quando l'hacker ha ottenuto il token di accesso e token di aggiornamento, cerca di rappresentare l'utente e utilizzare il nostro servizio. Ma dopo la breve-live token di accesso scade, quando i tentativi degli hacker per aggiornare il token di accesso, che, sul server, si è notato un cambiamento IP drammatico della storia del comportamento degli utenti (hey, questo ragazzo login in Stati Uniti e l'accesso ora di aggiornamento in Polonia dopo appena 3600s ???). Abbiamo terminare il processo di aggiornamento, invalidare il token di aggiornamento stesso e richiesta di inserire di nuovo il nome utente / password.

  3. L'utente è un dannoso utente. Ha lo scopo di abusare il nostro servizio chiamando il 1000 volte la nostra API ogni minuto usando un robot. Egli può ben farlo fino 3600 secondi più tardi, quando si tenta di aggiornare il token di accesso, abbiamo notato il suo comportamento e pensiamo che potrebbe non essere un essere umano. Rifiutiamo e terminare il processo di aggiornamento e gli chiediamo di inserire di nuovo il nome utente / password. Questo potrebbe potenzialmente interrompere il flusso automatico di suo robot. Almeno lo mette a disagio.

È possibile vedere il token di aggiornamento ha agito perfettamente quando cerchiamo di bilanciare il nostro lavoro, l'esperienza degli utenti e il potenziale rischio di un gettone rubato. Il vostro cane da guardia sul lato server può controllare più di cambiare IP, la frequenza delle chiamate API per determinare se l'utente deve essere un buon utente o meno.

Un'altra parola è che si può anche cercare di limitare il controllo dei danni di furto / abuso segno di servizio mediante l'attuazione su ogni chiamata API il cane base orologio IP o qualsiasi altra misura. Ma questo è costoso come si deve leggere e registrare scrittura sull'utente e rallenterà la risposta del server.

Nessuno di queste risposte arrivare alla ragione principale esistono aggiornamento gettoni. Ovviamente, si può sempre ottenere un nuovo accesso token / pair aggiornamento-token inviando le credenziali client al server di autenticazione -. Thats come li ottiene in primo luogo

Quindi, l'unico scopo del token di aggiornamento è quello di limitare l'uso delle credenziali del client vengono inviati attraverso la rete al servizio di autenticazione. Più breve è il TTL del token di accesso, più spesso le credenziali del client dovranno essere utilizzati per ottenere un nuovo token di accesso, e quindi più opportunità attaccanti scendere a compromessi le credenziali del client (anche se questo può essere super difficile, in ogni caso se crittografia asimmetrica viene utilizzato per inviare loro). Quindi, se si dispone di un singolo uso di aggiornamento-token, è possibile effettuare il TTL di accesso-gettoni arbitrariamente piccola, senza compromettere le credenziali del client.

Per chiarire una certa confusione bisogna capire i ruoli del cliente segreto e password utente , che sono molto diversi.

client è un app / sito / programma / ..., sostenuta da un server, che vuole autenticazione utente di utilizzando un servizio di autenticazione di terze parti. Il segreto del client è una stringa (casuale) che è noto sia per questo client e il server di autenticazione. Utilizzando questo segreto il cliente può identificarsi con il server di autenticazione, la ricezione di autorizzazione per i token di accesso richiesta.

Per ottenere l'accesso iniziale token e token di aggiornamento, ciò che è richiesto è:

  • L'ID utente
  • La password utente
  • L'ID cliente
  • Il segreto cliente

Per ottenere un accesso rinfrescata gettone tuttavia la client utilizza le seguenti informazioni:

  • L'ID cliente
  • Il segreto cliente
  • Il token di aggiornamento

Questo mostra chiaramente la differenza: durante l'aggiornamento, il cliente riceve l'autorizzazione a token di accesso di aggiornamento utilizzando il suo segreto cliente, e può quindi ri-autenticare l'utente che utilizza il token di aggiornamento al posto dell'ID utente + password. Questo previene efficacemente l'utente dal dover ri-entrare nel suo / la sua password.

Questo mostra anche che la perdita di un token di aggiornamento non è un problema perché l'ID cliente e segreto non sono noti. Essa mostra anche che mantenere l'ID cliente e segreto cliente segreto è vitale .

Questa risposta è da Justin Richer tramite la lista e-mail corpo standard di OAuth 2. Questo è pubblicato con il suo permesso.

La durata di un token di aggiornamento è fino al server delle autorizzazioni (AS) - possono scadere, essere revocata, ecc La differenza tra un token di aggiornamento e di un token di accesso è il pubblico: il token di aggiornamento risale solo al server di autorizzazione, il token di accesso va al (RS) del server delle risorse.

Inoltre, solo ottenere un token di accesso non significa che l'utente ha effettuato l'accesso. In realtà, l'utente potrebbe anche non essere più lì, che è in realtà il caso d'uso previsto del token di aggiornamento. Aggiornamento del token di accesso vi darà accesso a un'API per conto dell'utente, non vi dirà se l'utente lì.

OpenID Connect non solo darvi le informazioni utente da un token di accesso, ti dà anche un token ID. Si tratta di un foglio di dati che sono diretti al cliente stesso, non il AS o RS. In OIDC, si dovrebbe prendere in considerazione solo qualcuno in realtà “loggato” dal protocollo se è possibile ottenere un token ID fresca. Rinfrescante, non è probabile che sia sufficiente.

Per ulteriori informazioni si prega di leggere http://oauth.net/articles/authentication/

I clienti possono essere compromessi in molti modi. Per esempio, un telefono cellulare può essere clonato. Avere un token di accesso scade significa che il client è costretto a ri-autenticazione al server di autorizzazione. Durante la ri-autenticazione, il server di autorizzazione può controllare altre caratteristiche (IOW eseguire la gestione degli accessi adattivo).

gettoni Aggiorna consentono un client solo ri-autenticazione, dove, come le forze di ri-autorizzare un dialogo con l'utente che molti hanno indicato che piuttosto sarebbe non fare.

Aggiorna gettoni in forma in sostanza, nello stesso luogo in cui le normali siti web potrebbero scegliere di riautenticare periodicamente gli utenti dopo un'ora o giù di lì (ad esempio sito di banking). Non è molto utilizzato al momento poiché la maggior parte siti web sociali non ri-autenticare gli utenti web, quindi perché dovrebbero ri-autenticare un client?

Per semplificare ulteriormente la risposta di BT: Usa aggiornamento gettoni, quando non si vuole in genere che l'utente disponga di digitare le credenziali di nuovo, ma non vuole rinunciare al potere di essere in grado di revocare i permessi (revocando il token di aggiornamento)

Non è possibile revocare un token di accesso, solo un gettone di aggiornamento.

  

Perché non basta fare l'access_token ultima fino a quando il refresh_token   e non hanno un refresh_token?

Oltre alle grandi risposte altre persone hanno fornito c'è un altro motivo per cui avrebbe utilizzato i token di aggiornamento e la sua a che fare con i reclami.

Ogni token contiene affermazioni che possono includere qualsiasi cosa, da nome degli utenti, i loro ruoli e il provider che ha creato il credito. Come segno viene aggiornata queste affermazioni vengono aggiornati.

Se si aggiornano i gettoni più spesso ci sono, ovviamente, mettere più dura prova i nostri servizi di identità però siamo sempre più accurata e up-to-date richieste.

Si supponga a fare la access_token durare molto a lungo, e non hanno refresh_token, quindi in un solo giorno, hacker di ottenere questo access_token e può accedere a tutte le risorse protette!

Ma se avete refresh_token, il tempo in diretta del access_token è breve, quindi l'hacker è difficile incidere il vostro access_token perché sarà valido dopo breve periodo di tempo. Access_token possono essere recuperate solo indietro utilizzando non solo refresh_token ma anche da client_id e client_secret, che degli hacker non ha.

Mentre token di aggiornamento viene conservata dal server di autorizzazione. Token di accesso sono indipendenti in modo server di risorse in grado di verificare senza memorizzarlo che consente di risparmiare la fatica di recupero in caso di convalida. Un altro punto in discussione è mancante da rfc6749 # page-55

  

"Per esempio, il server autorizzazione potrebbe impiegare token di aggiornamento   la rotazione in cui un nuovo token di aggiornamento viene rilasciato con ogni accesso   token di aggiornamento risposta.L'elettrodo precedente token di aggiornamento viene invalidata, ma   conservato dal server di autorizzazione. Se un token di aggiornamento è   compromesso e successivamente utilizzato sia l'attaccante che il   legittima cliente, uno di loro presenterà un aggiornamento invalidata   token, che informerà il server di autorizzazione della violazione ".

Credo che il punto di utilizzo di token di aggiornamento è che anche se attaccante riesce in qualche modo per ottenere token di aggiornamento, ID cliente e associazione segreta. Con le chiamate successive per ottenere il nuovo token di accesso dal aggressore può essere rintracciato nel caso se ogni richiesta per il risultato di aggiornamento nel nuovo token di accesso e token di aggiornamento.

Questa risposta è stato messo insieme con l'aiuto di due sviluppatori di alto livello (John Brayton e David Jennes).

Il motivo principale per utilizzare un token di aggiornamento è quello di ridurre la superficie di attacco.

Supponiamo non c'è una chiave di aggiornamento e andiamo attraverso questo esempio:

Un edificio dispone di 80 porte. Tutte le porte sono aperte con la stessa chiave. La chiave cambia ogni 30 minuti.

Se io sono l'hacker e ottenere la chiave, poi alla fine dei 30 minuti, io corriere che al keymaker e ottenere una nuova chiave. Sarò in grado di aprire in modo continuo tutte le porte a prescindere dal cambiamento chiave.

Domanda: Durante i 30 minuti, quante opportunità di hacking ho dovuto contro la chiave? Ho avuto 80 opportunità di hacking, ogni volta che è stato utilizzato il tasto (pensare a questo come fare una richiesta di rete e passare il token di accesso per identificare se stessi). Quindi, questo è 80X superficie di attacco.

Ora andiamo attraverso lo stesso esempio, ma questa volta supponiamo che ci sia una chiave di aggiornamento.

Un edificio dispone di 80 porte. Tutte le porte sono aperte con la stessa chiave. La chiave cambia ogni 30 minuti. Se io sono l'hacker e ottenere la chiave, posso usarlo per 30 minuti, ma alla fine dei 30 minuti di inviarlo al Keymaker non ha alcun valore. Se lo faccio, poi il Keymaker sarebbe solo dire questa chiave è scaduto. Per essere in grado di estendere il mio mod avrei dovuto incidere il corriere per la Keymaker. Il corriere ha una chiave diversa (pensare a questo come un segno di aggiornamento).

Domanda: Durante i 30 minuti, quante opportunità di hacking ho dovuto nei confronti del corriere? 80? No. Ho avuto solo 1 hacker opportunità. Durante il tempo del corriere comunica con il keymaker. Quindi, questo è 1X superficie di attacco. Ho avuto 80 di hacking opportunità contro la chiave, ma sono nulla di buono dopo 30 minuti.

Un server potrebbe verificare un token di accesso in base alle credenziali e la firma di (in genere) un JWT.

Un token di accesso che perde è male, ma una volta che scade non è più utile è quello di un attaccante. Una pedina che perde di aggiornamento è di gran lunga peggiore, ma presumibilmente è meno probabile. (Penso che ci sia spazio per questione se la probabilità di una fuoriuscita di token di aggiornamento è molto inferiore a quella di un token di accesso che perde, ma questa è l'idea.)

Punto è che il token di accesso viene aggiunto a ogni richiesta si effettua, mentre un token di aggiornamento viene utilizzata solo durante il flusso di aggiornamento Quindi, meno possibilità di un MITM vedere il token

Frequenza aiuta un attaccante. heartbleed -come potenziali falle di sicurezza in SSL, potenziali falle di sicurezza nel client e potenziali falle di sicurezza nel server tutti i make perdite possibile.

Inoltre, se il server di autorizzazione è separato dal server applicazioni che elabora le altre richieste dei client allora che application server non potrà mai vedere i token di aggiornamento. Si vedrà solo token di accesso che non vivrà molto più a lungo.

Compartimentalizzazione è buono per la sicurezza.

Che token di aggiornamento non si tratta di?

La possibilità di aggiornamento / livello di accesso Revoca attraverso i token di aggiornamento è un sottoprodotto di scegliere di usare i token di aggiornamento, altrimenti un token di accesso autonomo potrebbe essere revocato o avere il suo livello di accesso modificata quando scade e gli utenti ottiene un nuovo token”

Consideriamo un sistema in cui ogni utente è collegato a uno o più ruoli e ogni ruolo è legato a uno o più privilegi di accesso. Queste informazioni possono essere memorizzate nella cache per migliorare le prestazioni API. Ma poi, ci possono essere cambiamenti nelle configurazioni utenti e dei ruoli (per esempio nuovo accesso può essere concesso o accesso corrente può essere revocato) e questi dovrebbe riflettersi nella cache.

Si può utilizzare l'accesso e aggiornare i token per tale scopo. Quando un API viene richiamato con token di accesso, il server di risorse controlla la cache per i diritti di accesso. Se ci sono dei nuovi sussidi di accesso, non si riflette immediatamente. Una volta che il token di accesso scade (diciamo in 30 minuti) e il client utilizza il token di aggiornamento per generare un nuovo token di accesso, la cache può essere aggiornato con l'accesso degli utenti informazioni aggiornate direttamente dal DB.

In altre parole, si può spostare le operazioni costose da ogni chiamata API utilizzando token di accesso al caso di accesso generazione del token utilizzando token di aggiornamento.

  

In primo luogo, i autentica client con il server di autorizzazione, dando la concessione dell'autorizzazione.

     

Quindi, il client richiede il server risorsa per risorsa protetta dando il token di accesso.

     

Il server risorsa convalida il token di accesso e fornisce la risorsa protetta.

     

Il client effettua la richiesta risorsa protetta al server risorsa concedendo il token di accesso, in cui il server di risorse convalida e serve la richiesta, se valido. Questo passaggio continua a ripetere fino a quando il token di accesso scade.

     

Se il token di accesso scade, i autentica client con il server di autorizzazione e le richieste per un nuovo token di accesso, fornendo token di aggiornamento. Se il token di accesso non è valido, il server di risorsa restituisce la risposta non valida errore di token per il cliente.

     

I autentica client con il server di autorizzazione concedendo il token di aggiornamento.

     

Il server di autorizzazione quindi convalida il token di aggiornamento per l'autenticazione del cliente e problemi di un nuovo token di accesso, se è valido.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top