Il posto migliore per archiviare i token di autenticazione lato client

Esistono due modi per salvare le informazioni di autenticazione nel browser:

1. Cookie
2. Archiviazione Web HTML5

In ogni caso, devi avere fiducia che i browser siano implementati correttamente e che il sito Web A non possa in qualche modo accedere alle informazioni di autenticazione per il sito Web B. In tal senso, entrambi i meccanismi di archiviazione sono ugualmente sicuri. I problemi possono sorgere in termini di come li si usa però.

Se usi i cookie:

• Il browser invierà automaticamente le informazioni di autenticazione con ogni richiesta all'API. Questo può essere conveniente finché sai che sta accadendo.
• Devi ricordare che CSRF è una cosa e gestirla.

Se si utilizza l'archiviazione Web HTML5:

• Devi scrivere Javascript che gestisce esattamente quando e quali informazioni di autenticazione vengono inviate.

La grande differenza che interessa alle persone è che con i cookie, devi preoccuparti di CSRF. Per gestire correttamente CSRF, di solito è necessario un token di sincronizzazione aggiuntivo ".

I framework web all-in-one (come Grails, Rails, probabilmente asp.net) di solito forniscono un modo semplice per abilitare la protezione CSRF e aggiungono automaticamente roba token sincronizzatore nell'interfaccia utente. Ma se stai scrivendo un'interfaccia utente utilizzando un framework web solo client-side (come AngularJS o BackboneJS), dovrai scrivere alcuni Javascript per gestire il token di sincronizzazione. Quindi in questo caso potresti anche semplicemente adottare l'approccio di archiviazione Web HTML5 e preoccuparti solo di un token.

Alcune altre differenze sono discusse qui .

modifica una ricerca su google rivela questo per asp.net - chiamano il token di sincronizzazione un" token di verifica della richiesta ".

Il modo più sicuro per archiviare il tuo token di accesso è semplicemente non memorizzarlo affatto sul lato client.

Come funziona? Bene al punto di generare il token di accesso, genera un altro PRNG crittograficamente sicuro (che mappi al token di accesso sul server), mappalo all'ID della sessione utente e restituiscilo al client.

Questo ridurrà l'area di attacco perché ciò che si sta restituendo è un token legato a una sessione, ed entrambi sarebbero necessari per autorizzare il token. Quando la sessione scade lo fa anche il token, naturalmente, e l'utente sarebbe costretto a re-autenticare generando così un nuovo token di accesso.

Non è ancora sicuro al 100%, tuttavia, è necessario valutare la possibilità che qualcosa di simile avvenga all'interno di una sessione di utenti. Sulla base di ciò, è possibile modificare i tempi di scadenza della sessione / token per adattarli, sebbene sia anche necessario essere stanchi dell'usabilità: non si desidera che le sessioni scadano dopo 5 minuti poiché è necessario riconnettersi costantemente può essere noioso ( o forse puoi, dipende dal tipo di applicazione).

ARMOR è progettato specificamente per soddisfare questo requisito. Il token anti-contraffazione può essere memorizzato ovunque nell'interfaccia utente che ritieni opportuno. La libreria viene fornita con un componente JavaScript personalizzato che estrae il token dall'interfaccia utente e lo include automaticamente nelle intestazioni AJAX.

Ecco un tutorial sull'argomento, e ecco il repository GitHub .

Il blog di Alex deve essere informativo.

A server dies every time someone implements OAuth in a single page is web app. Stop the genocide! Use a server side proxy! Act now!

link

Devi inviare il token al server in ogni requset. Quindi non importa che lo memorizzi in cookie o in html 5. Entrambi sono archivi sicuri e chiunque abbia accesso al computer client ha comunque accesso al token.

Tuttavia, consiglio di non utilizzare il token inviato nel cookie sul tuo server per impedire l'attacco CSRF. Penso che sia una buona idea includere manualmente il token in ogni richiesta che fai quando richiesto.

L'uso del cookie rende anche l'intestazione della richiesta più grande che non è appropriata.