Autenticazione Token che memorizza dopo l'autenticazione del database

2

Ho lavorato a un'applicazione di backend MVC RESTful per Spring 4. Autentiamo su un server OpenAM e un token lungo è memorizzato in un cookie sul front-end. Il front-end estrae il token dal cookie e lo restituisce come intestazione in ogni chiamata Ajax al back-end. Quindi, se chiamiamo il backend RESTful in una chiamata Ajax (POST, PUT, GET), il token viene inviato come header chiamato "openam_token."

Abbiamo implementato Spring Web-Security in base all'esempio SiteHeader. Un token arriva come intestazione e abbiamo un PreAuthorizationFilter che abbiamo implementato chiamato "CustomUserDetailsService." Questo codice prende l'intestazione e prende il token, passiamo quel token ad OpenAM per chiedere se questo è valido, e in caso affermativo, ci restituisce il nome utente di quell'utente. Da quel nome utente univoco, possiamo cercare l'utente nel database e ottenere i dettagli dell'utente e i loro ruoli.

Presumo che se ho creato un accesso da Google+, LinkedIn o Facebook, il processo è lo stesso. Passiamo alla pagina di accesso, l'utente viene autenticato e quindi un token ritorna. Il token viene memorizzato in un cookie sul lato client. Ogni chiamata Ajax da quel front-end al backend restituisce il token nell'intestazione, quindi in CustomUserDetailsService ... chiamiamo LinkedIn, Google+ o Facebook e vediamo se l'utente è corretto. Ma questo è sulla mia presunzione di come funzionano, ma potrei sbagliarmi completamente.

Quindi, sull'app RESTful di primavera su cui sto lavorando. I nomi utente e le password sono memorizzati nel database insieme al sale. Ho fatto molte ricerche sulla memorizzazione di Salt con lo username, un salt unico generato quando l'utente viene creato o quando cambia la sua password.

Quindi, a condizione che un utente fornisca un nome utente e una password e l'utente si sia autenticato ... Voglio generare un token per questo utente e mi chiedo quali sono le pratiche comuni per generare un token?

In secondo luogo, dove è il posto migliore per memorizzare quel token? Se il token ritorna, suppongo di poterlo salvare in un cookie anche dal lato client, proprio come facciamo quando autenticiamo con OpenAM. Ora, quale sarebbe il modo migliore per memorizzare quei token temporanei sul back-end? Potrei persistere il token nella tabella utenti insieme all'utente. Potrei conservare quei token in un altro tavolo. L'idea è ... i token, memorizzati nei cookie, devono corrispondere sul back-end per quell'utente con quel token. Quindi, la domanda è su quale strategia godd per farlo.

Capisco che non avrò mai il sito più sicuro al 100%, ma posso prendere alcune misure comuni e svolgere la mia due diligence.

Sembra una tremenda spiegazione per qualcosa che sembra una domanda facile.

Grazie!

    
posta tjholmes66 12.09.2016 - 18:46
fonte

1 risposta

1

Lunghezza del token di 256 bit, 42 caratteri in base64. Deve essere casuale.

Il token è solitamente memorizzato nella cache con la sessione utente. Ad esempio, Redis. Ogni altro metodo di memorizzazione farebbe e varierà con la reattività, ad es. il recupero di JSON lungo da tmpfs e dal DB SQL è diverso. La compressione aiuta.

Questo può essere un altro servizio locale. Ad esempio, il servizio token che contiene le chiavi API.

    
risposta data 13.09.2016 - 00:32
fonte

Leggi altre domande sui tag