2013-04-27 1 views
11

Attualmente sto implementando un'architettura OAuth 2.0 per la mia API RESTful.Controlla token di accesso ogni richiesta con Redis

Con ogni richiesta ho creato un autorizzazione portatore token nell'intestazione HTTP per tutti i miei clienti per effettuare richieste Autorizzati.

Authorization: Bearer sdflksd3r4823vkn95-03850432 

Capisco che è pratica comune di accettare solo il token nelle API fino alla data di scadenza. Ma diciamo che se un utente desiderava revocare il token, avrei bisogno di utilizzare un metodo per controllare lo stato del token con ogni richiesta.

Stavo pensando di andare al Db per verificare ogni richiesta HTTP. Ho la sensazione che questo non si ridimensionerà bene a causa di motivi di prestazioni.

Quindi mi chiedevo se una soluzione come Redis sarebbe appropriata per letture singole molto veloci dello stato del token di accesso?

risposta

9

Il punto di avere un HMAC per un token è in modo che il server possa verificare rapidamente senza l'intervento di qualsiasi archivio dati esterno (ad es Redis, MySQL, ecc). Questo ha l'ulteriore vantaggio di adattarsi bene a più server poiché non esiste uno stato condiviso (tutte le informazioni per verificare il token sono il token stesso e la chiave per l'HMAC).

Se si dispone di una lista nera di token revocati, qualcosa come Redis probabilmente andrebbe bene (anche se è ancora più lento di non effettuare una chiamata remota per ogni verifica token). Configura correttamente, con bassa latenza tra l'istanza Redis e il/i server/i API, dovresti vedere < 10 ms per richiesta.

Bonus: Un'altra opzione per accelerare ulteriormente le cose sarebbe utilizzare un Bloom filter per gestire la memorizzazione nella cache delle richieste API rifiutate. In questo modo si passa a Redis solo se il filtro Bloom contrassegna il token di richiesta come eventualmente revocato. Si noti che poiché questo è un altro livello di memorizzazione nella cache, è necessario aggiornare lo stato del filtro Bloom quando un token viene rifiutato.

+0

Stavo considerando un filtro di fioritura. Anche se mi chiedevo anche se l'utilizzo di una cache singleton fosse un'opzione valida –

+1

Se si dispone di un solo server, si hanno molte più opzioni in quanto è sufficiente mantenere lo stato in un unico posto. Avere un server esterno come Redis mantiene lo stato consente di avere più server API. Un singleton funziona solo se si dispone di un singolo server. Un'altra alternativa sarebbe una mappa distribuita (Coherence, Hazelcast, ecc.). Se i token hanno scadenze relativamente brevi, allora puoi anche rimuovere dalla mappa distribuita quando scadono per ridurne le dimensioni. – sehrope

+0

Risposte eccellenti. Molte grazie! –

2

Sto facendo qualcosa di simile per me stesso.
Per la sintassi dei token e la crittografia, suggerisco di utilizzare JWT, è un buon standard per questo.
Va bene utilizzare i redis per memorizzare un token di coppia/id utente, anche perché è possibile impostare un valore di scadenza.
Inoltre ho inserito un filtro fioritura nel mezzo, ma reso in modo opposto rispetto sehrope suggerimento: sto memorizzare tutti i gettoni al login in fiore dal filtro, per cui se il token non è presente, è sicuramente valido ; altrimenti è probabilmente corretto, ma devo essere sicuro di fare un controllo su Redis; ma ora ho un problema: se voglio scalare il mio sistema di autenticazione ho bisogno di un load balancer statico tra i server di autenticazione. IMHO, usare un filtro di fioritura per creare una lista nera non è corretto: se io inserisco nella blacklist i token revocati e sbagliati, se l'elemento non è nella lista nera il filtro bloom restituisce false (e devo verificarlo in backend redis) per autorizzare); altrimenti se un elemento è presente (nella blacklist) devo verificarlo sui redis per essere sicuro perché la risposta true filter filter può essere un falso positivo.

+0

Attualmente sto usando un token JWT sul mio sito AngularJS memorizzato in sessionStorage. Dovranno effettuare il login ogni volta che l'applicazione browser viene chiusa. Questo è anche un tempo di scadenza di 30 minuti prima che un utente debba essere riemesso da un altro token. Io uso semplicemente i redis per prenderne nota e mi permette di trovare i token molto velocemente. –

6

ho realizzato qualcosa di simile per la movimentazione revocato gettone generato da JWT.

sto usando Redis per impostare i token revocati con una scadenza, in modo che i gettoni vengono automaticamente eliminati dalla Redis. E ho un middleware per controllare in redis il token fornito. Controlla il full post here.Spero che lo aiuti