Svantaggi di memorizzare un token di autenticazione sul lato client?

Dato che farai chiamate al server API tramite Ajax (il che significa che la stessa pagina e lo stesso contesto JavaScript saranno costanti) ti suggerirei di creare un token di breve durata nel server principale, con la richiesta del browser una volta, quindi utilizzandolo per l'autenticazione con il server API fino a quando la pagina non viene chiusa (o il token scade, a seconda di quale evento si verifichi prima). La prossima volta che l'utente visita la pagina, genera un nuovo token.

In questo modo le chiamate al server principale saranno rare (e non è possibile evitarle comunque, poiché ogni volta che l'utente si disconnette o cancella i cookie dovrà autenticarsi nuovamente con il sito principale), e tu evitare il fastidio di dover proteggere ancora un altro pezzo di dati.

Come per i vettori di attacco Local Storage, credo che in teoria siano approssimativamente uguali a quelli relativi ai cookie: XSS, accesso fisico alla macchina, ecc. poiché è soggetto allo stesso Politica di origine (almeno quelli creati da una pagina protetta da SSL), ma contrariamente ai cookie, non supporta una visibilità limitata per percorso (cioè tutte le pagine del dominio possono accedere ai dati da qualsiasi altra pagina) . In pratica, tuttavia, potrebbero esserci incongruenze nel modo in cui è implementato, così come altri problemi di sicurezza, quindi non mi fiderei di esso a meno che non fossi molto sicuro che sia sicuro (qualcosa che non posso affermare con le mie attuali conoscenze). Secondo questa guida OWASP che memorizza i dati sensibili in Archiviazione locale è scoraggiata. SessionStorage è non a prova di proiettile .