Dove dovrei memorizzare un token di aggiornamento

Question

Dove dovrei memorizzare un token di aggiornamento

#1 da (3 voti)

7

Sto costruendo un protocollo oauth 2.0. Mi chiedo come funziona esattamente il token di aggiornamento.

La mia comprensione è che l'uso di un token di aggiornamento abilita token di accesso di breve durata e pertanto limita la vulnerabilità di tali token di accesso. Ottimo finora. Una volta scaduto un token di accesso, in qualche modo utilizzi il token di aggiornamento per ottenere un nuovo token di accesso.

Mi chiedo come faccia esattamente quest'ultima parte (senza interrompere il flusso utente effettuandone il logout):

per proteggere la transazione, se è necessario che l'ID app e il segreto dell'app vengano inviati lungo il token di aggiornamento, per garantire l'identità del richiedente?
- se è così, sembra che tu non voglia archiviare un'app segreta su un client (web o app mobile o altro), quindi come puoi farlo senza disconnettere l'utente?
- in caso contrario, qual è il punto del token di aggiornamento se non è possibile utilizzarlo per verificare l'identità del richiedente? E va bene memorizzare il token di aggiornamento in un client?

oauth credentials

posta Guig 14.07.2016 - 21:04

fonte

1 risposta

Leggi altre domande sui tag oauth credentials

Garantisce il flusso di OAuth 2 per l'applicazione client o mobile PHP Injection Vulnerability SQL In UPDATE Statements

score 3 · Answer 1

Comprendere un token di aggiornamento potrebbe causare più danni che compromettere il token di accesso.

Puoi utilizzare varie tecniche per renderlo più sicuro.

Puoi ottenere l'idea apprendendo una delle tecniche standard raccomandate per "The OAuth 2.0 Authorization Framework". Si prega di fare riferimento alla RFC .

È possibile separare la preoccupazione di accesso e autorizzazione mantenendo il server delle risorse separato e il server delle autorizzazioni. È possibile utilizzare solo il token di accesso (e non il token di aggiornamento) per accedere alla risorsa. È possibile utilizzare solo token di aggiornamento (e non token di accesso) per comunicare con il server di autorizzazione. Ciò riduce il rischio che il token di aggiornamento venga compromesso.

In secondo luogo, è più facile rilevare se il token di aggiornamento è compromesso. Diciamo che un token di aggiornamento è compreso e viene utilizzato per generare nuovi token di accesso. Una volta che questo token di aggiornamento è stato revocato, tutti i token di accesso generati già e questi ultimi verranno invalidati. In quanto tale, solo 1 parte sarà in grado di accedere alle risorse utilizzando i token di accesso generati utilizzando il singolo token di aggiornamento valido. Se più utenti partecipano, continueranno a invalidare l'un l'altro. Nel processo di rilevamento del token di aggiornamento, il compromesso diventa facile.