oauth oauth2 - Perché scadono i token di accesso?




facebook generator (5)

Sto solo iniziando a lavorare con Google API e OAuth2. Quando il client autorizza la mia app mi viene dato un "token di aggiornamento" e un "token di accesso" di breve durata. Ora, ogni volta che il token di accesso scade, POSSO POSTARE il mio token di aggiornamento a Google e mi daranno un nuovo token di accesso.

La mia domanda è qual è lo scopo del token di accesso in scadenza? Perché non può esserci un token di accesso di lunga durata invece del token di aggiornamento?

Inoltre, il token di aggiornamento scade?

Consulta Utilizzo di OAuth 2.0 per accedere alle API di Google per ulteriori informazioni sul flusso di lavoro di Google OAuth2.


Answers

È essenzialmente una misura di sicurezza. Se l'app viene compromessa, l'utente malintenzionato avrà accesso solo al token di accesso di breve durata e non sarà possibile generarne uno nuovo.

Anche i token di aggiornamento scadono, ma si suppone che vivano molto più a lungo del token di accesso.


Un paio di scenari potrebbero aiutare a illustrare lo scopo dell'accesso e dei token di aggiornamento e dei compromessi ingegneristici nella progettazione di un sistema oauth2 (o qualsiasi altro auth):

Scenario di app Web

Nello scenario della web app hai un paio di opzioni:

  1. se si dispone della propria gestione delle sessioni, archiviare sia access_token che refresh_token rispetto all'id di sessione nello stato di sessione sul servizio di stato della sessione. Quando viene richiesta una pagina da parte dell'utente che richiede di accedere alla risorsa, utilizzare access_token e se il token di accesso è scaduto, utilizzare refresh_token per ottenere quello nuovo.

Immaginiamo che qualcuno riesca a dirottare la tua sessione. L'unica cosa che è possibile è richiedere le tue pagine.

  1. se non si dispone della gestione delle sessioni, inserire access_token in un cookie e utilizzarlo come sessione. Quindi, ogni volta che l'utente richiede le pagine dal tuo server web, invia il token di accesso. Il tuo server delle app potrebbe aggiornare il token di accesso se necessario.

Confronto tra 1 e 2:

In 1, access_token e refresh_token viaggiano solo attraverso il cavo sulla strada tra il server di authorzation (google nel tuo caso) e il tuo server delle app. Questo sarebbe fatto su un canale sicuro. Un hacker potrebbe dirottare la sessione ma sarebbe solo in grado di interagire con la tua app web. In 2, l'hacker potrebbe portare via il token di accesso e formare le proprie richieste alle risorse a cui l'utente ha concesso l'accesso. Anche se l'hacker ottiene una presa di access_token avranno solo una breve finestra in cui potranno accedere alle risorse.

In entrambi i casi, refresh_token e clientid / secret sono noti al server solo rendendo impossibile l'accesso a lungo termine dal browser web.

Immaginiamo che stai implementando oauth2 e imposti un lungo timeout sul token di accesso:

In 1) Qui non c'è molta differenza tra un token di accesso breve e lungo poiché è nascosto nel server dell'app. In 2) qualcuno potrebbe ottenere access_token nel browser e quindi utilizzarlo per accedere direttamente alle risorse dell'utente per un lungo periodo.

Scenario mobile

Sul cellulare, ci sono un paio di scenari che io conosco:

  1. Memorizza clientid / secret sul dispositivo e fai orchestrare il dispositivo ottenendo l'accesso alle risorse dell'utente.

  2. Utilizza un app server back-end per tenere il clientid / segreto e fargli fare l'orchestrazione. Utilizzare access_token come un tipo di chiave di sessione e passarlo tra il client e il server dell'app.

Confronto tra 1 e 2

In 1) Una volta che hai client / secret sul dispositivo non sono più segreti. Chiunque può decompilare e quindi iniziare a comportarsi come se fossi tu, con il permesso dell'utente, ovviamente. Anche access_token e refresh_token sono in memoria e potrebbero essere accessibili su un dispositivo compromesso, il che significa che qualcuno potrebbe agire come app senza che l'utente abbia fornito le proprie credenziali. In questo scenario, la lunghezza di access_token non fa alcuna differenza rispetto all'hackability dal momento che refresh_token si trova nella stessa posizione di access_token. In 2) il clientid / segreto e il token di aggiornamento sono compromessi. Qui la lunghezza della scadenza del token_accesso determina per quanto tempo un hacker può accedere alle risorse degli utenti, nel caso in cui ne venga a conoscenza.

Lunghezze di scadenza

Qui dipende da cosa si sta proteggendo con il proprio sistema di autenticazione per quanto tempo dovrebbe essere la scadenza del tuo access_token. Se è qualcosa di particolarmente prezioso per l'utente, dovrebbe essere breve. Qualcosa di meno prezioso, può essere più lungo.

Alcune persone come google non scadono il refresh_token. Alcuni come lo stackflow. La decisione sulla scadenza è un compromesso tra facilità e sicurezza dell'utente. La lunghezza del token di aggiornamento è correlata alla lunghezza di ritorno dell'utente, ovvero imposta l'aggiornamento sulla frequenza con cui l'utente torna alla tua app. Se il token di aggiornamento non scade, l'unico modo in cui vengono revocati è con un revoca esplicita. Normalmente, un accesso non si revoca.

Spero che un post piuttosto lungo sia utile.


Questo è molto specifico per l'implementazione, ma l'idea generale è di consentire ai fornitori di rilasciare token di accesso a breve termine con token di aggiornamento a lungo termine. Perché?

  • Molti provider supportano token bearer che sono molto deboli in termini di sicurezza. Rendendoli di breve durata e richiedendo un aggiornamento, limitano il tempo che un utente malintenzionato può abusare di un token rubato.
  • La distribuzione su larga scala non vuole eseguire una ricerca nel database ogni chiamata API, quindi invece emette un token di accesso auto codificato che può essere verificato tramite decodifica. Tuttavia, ciò significa anche che non è possibile revocare questi token in modo che vengano rilasciati per un breve periodo e che debbano essere aggiornati.
  • Il token di aggiornamento richiede l'autenticazione del client che lo rende più forte. A differenza dei suddetti token di accesso, di solito è implementato con una ricerca nel database.

Oltre alle altre risposte:

Una volta ottenuti, i token di accesso vengono generalmente inviati insieme a tutte le richieste dai client ai server di risorse protetti. Ciò induce un rischio di accesso al furto e alla riproduzione di token (presupponendo ovviamente che i token di accesso siano di tipo "Bearer" (come definito nella RFC6750 iniziale).

Esempi di tali rischi, nella vita reale:

  • I server di risorse in genere sono server di applicazioni distribuiti e in genere hanno livelli di sicurezza inferiori rispetto ai server di autorizzazione (configurazione SSL / TLS inferiore, minore protezione, ecc.). I server di autorizzazione, d'altra parte, sono generalmente considerati un'infrastruttura di sicurezza critica e sono soggetti a un rafforzamento più severo.

  • I token di accesso possono essere visualizzati nelle tracce HTTP, nei registri, ecc. Che vengono raccolti legittimamente per scopi diagnostici sui server di risorse o sui client. Queste tracce possono essere scambiate su luoghi pubblici o semi-pubblici (tracciatori di bug, service-desk, ecc.).

  • Le applicazioni backend RS possono essere esternalizzate a terze parti più o meno affidabili.

Il token di aggiornamento, d'altro canto, viene tipicamente trasmesso solo due volte sui fili e sempre tra il client e il server di autorizzazione: una volta ottenuto dal client e una volta utilizzato dal client durante l'aggiornamento (in modo efficace "in scadenza" l'aggiornamento precedente gettone). Questa è un'opportunità drasticamente limitata per l'intercettazione e la riproduzione.

Ultimo pensiero, i token di aggiornamento offrono pochissima protezione, se esiste, contro i client compromessi.


Penso che Will Cain abbia risposto a questa domanda dicendo "Non c'è alcun vantaggio per le credenziali del cliente per lo stesso motivo. (Qualsiasi client può tentare di utilizzare questo flusso.)" Inoltre considera redirect_uri per il flusso implicito forse "localhost" - nessuna richiamata viene creato dal server di autorizzazione per il flusso implicito. Poiché non c'è modo di pre-fidarsi del client, l'utente dovrebbe approvare il rilascio delle attestazioni dell'utente.







oauth oauth-2.0 google-api google-oauth