Perché dovrei mantenere i token di accesso OAuth 2 insieme al token di aggiornamento

Question

Perché dovrei mantenere i token di accesso OAuth 2 insieme al token di aggiornamento

#1 da (6 voti)
#2 da (1 voti)

10

Questo è qualcosa che ho trovato in un paio di articoli su OAuth 2: quando si tratta di persistere token di aggiornamento nel database, alcuni autori preferiscono archiviare anche il token di accesso, o almeno menzionarlo come qualcosa che dovresti fare. E quando si tratta di garantire l'accesso basato su refresh_token , un ticket viene prelevato dal database, deserializzato, aggiornato e inviato all'utente con un nuovo token di aggiornamento.

Ecco un esempio della tabella RefreshTokens , in cui la colonna ProtectedTicket mantiene serializzato access_tokens rilasciato all'utente:

Finora posso pensare ad almeno 3 ragioni contro questo approccio:

Non è una minaccia per la sicurezza quando si conservano i ticket di accesso degli utenti, solo in attesa che qualcuno li catturi e riutilizzati per un server delle risorse insospettabile? L'hash unidirezionale non può essere utilizzato, poiché è necessario deserializzare, aggiornare e inviarlo all'utente e non vogliamo mantenere anche i token di accesso validi.
Ad esempio, si desidera aggiornare la chiave di crittografia utilizzata per serializzare / deserializzare il biglietto una volta ogni tanto nel caso in cui. Se non vuoi che i tuoi utenti vengano disconnessi una volta scaduto il loro access_token , devi preoccuparti di aggiornare quei biglietti persistenti.
Devi scrivere una porzione di codice a seconda di quanto sei preoccupato per # 1 e # 2 . Forse persino tu implementi alcuni hack sporchi attorno a te, il framework OAuth, in quanto potrebbe non fornire i punti di estensibilità di cui avrai bisogno.

Quindi le domande sono, perché vuoi fare tutto questo? Che tipo di vantaggio dovrebbe dare per far sì che valga davvero la pena? Non è più facile , più sicuro e più mantenibile solo per creare un nuovo ticket una volta verificato refresh_token ?

authentication oauth key-management

posta 2ooom 29.10.2014 - 09:49

fonte

2 risposte

Leggi altre domande sui tag authentication oauth key-management

Come diventare Autorità di certificazione intermedia? Richiesta HEAD molto lunga nei log del server: qual è l'intenzione?

score 6 · Answer 1

Quale sarebbe il punto di hashing the accessToken?

Abbiamo le password hash perché le persone le riutilizzano ovunque. Se non riutilizzassero le password, non avremmo bisogno di hash password, l'applicazione è stata compromessa dopo tutto (come l'attaccante ha ottenuto l'accesso al db), quindi tutto è già perso.

accessTokens non vengono riutilizzati . e aggiungendo alla sicurezza, vengono utilizzati solo una volta (per 10 minuti, ad esempio, a seconda della durata del token). Quindi, perché dovremmo averli hash? I RefreshToken possono essere utilizzati per ottenere più token di accesso, motivo per cui sembra ragionevole cancellarli, ma anche questo è discutibile poiché refreshTokens non viene utilizzato tra le applicazioni.

Se lo desideri, potresti pensare a crittografare gli accessTokens, ma supponiamo che l'intera applicazione sia stata compromessa, inclusa la chiave di crittografia. A proposito, non memorizzi realmente un AccessToken, piuttosto memorizzi il ticket per ottenere un AccessToken, ma ciò non cambia la rilevanza della tua domanda.

score 1 · Answer 2

La risposta è molto probabilmente legata alle prestazioni.

I token di accesso OAuth2 sono progettati per essere di breve durata, mentre i token di aggiornamento sono progettati per essere più longevi in quanto possono essere utilizzati per ottenere nuovi token di accesso. La maggior parte delle librerie client è progettata per memorizzare nella cache il token di accesso OAuth per evitare di colpire il server delle autorizzazioni. Vedi qui:

link

/// <summary>
/// Default implementation is to try to refresh the access token if there is no access token or if we are 1 
/// minute away from expiration. If token server is unavailable, it will try to use the access token even if 
/// has expired. If successful, it will call <see cref="IAccessMethod.Intercept"/>.
/// </summary>
        public async Task InterceptAsync(HttpRequestMessage request, CancellationToken taskCancellationToken)
[...]

Se visiti il parco giochi Google OAuth2, puoi vedere alcuni di questi in azione: link

Quando autorizzi un'API (prova a digitare "profilo" in per un ambito personalizzato e fai clic su "Autorizza API" se non vuoi fare clic sull'elenco), dopo aver effettuato lo scambio di autenticazione e ricevuto un accesso / Aggiorna token, vedrai quanto segue:

"Il token di accesso scadrà tra [countdown] secondi.

[] Aggiorna automaticamente il token prima che scada. "

Memorizzando nella cache o archiviando il token di accesso, si impedisce di effettuare un round trip sul server di autorizzazione per scambiare il token di aggiornamento per un token di accesso (protezione da latenze e interruzioni del server di autorizzazione). Alcuni server possono anche limitare la frequenza con cui è possibile scambiare un token di aggiornamento per un token di accesso (la generazione di un token di accesso può comportare un'operazione di crittografia "costosa", ad esempio).

Perdere il token di accesso è "cattivo" nel senso che può essere usato senza altre informazioni al fine di affermare l'identità della persona che lo ha concesso - ma è in qualche modo mitigato dal fatto che i token di accesso hanno una durata limitata, aumentare la pressione sull'attaccante per inclinare immediatamente la mano / usare i valori. Perdere il token di aggiornamento è (teoricamente) "peggiore" dal momento che consentirebbe l'accesso perpetuo, tuttavia ciò che rende questo più complicato è che facendo un refresh < - > lo scambio di token di accesso richiede anche la conoscenza del tuo client_secret OAuth2.

Nel modello attuale che descrivi, non è chiaro se ProtectedTicket sia crittografato (si dice che è serializzato, ma in seguito si parla dell'aggiornamento dei ticket persistenti). Se si stanno crittografando i token di accesso nel database per proteggerli da un utilizzo (errato) da parte di coloro che dispongono dell'accesso al database amministrativo, è possibile esaminare soluzioni per gestire chiavi con versione, che consentono di ruotare la chiave di crittografia. Uno che conosco è link , e qualcuno ha creato binding .NET per questo (presumo dal tuo screenshot che sei su .NET).

KeyCzar può fornire un modo semplice per risolvere alcuni dei tuoi dubbi, ma molte delle effettive proprietà di sicurezza del tuo sistema dipenderanno dal tuo modello di minaccia e da molti fattori oltre lo schema del database.