Se dovessi implementare un modello di connessione OpenID comune su una SPA, potrei avere la seguente relazione:
Auth server <-----------> Client (browser) <-----------> App API server
L'utente verrebbe reindirizzato al server di autenticazione per accedere e un cookie Solo HTTP è impostato sul server di autenticazione con il token ID dell'utente (il cui carico contiene i dettagli dell'utente e firmato da un segreto) e il token di autenticazione. Quindi il server auth reindirizza l'utente all'app con i token nella stringa hash, in modo che possano essere mantenuti.
L'hash dovrebbe essere impostato facendo in modo che l'API restituisca qualcosa come:
res.send('<script>
location.replace('${callbackUrl}#access_token=${accessToken}&id_token=${idToken}')
</script>')
piuttosto che un reindirizzamento HTTP con il token nella stringa di query (perché probabilmente verrebbe registrato) e l'app lato client può utilizzare history.replaceState() per cancellare i token dalla cronologia del browser. Il browser rimuove questi token dall'hash in modo che l'utente non accidentalmente legga o condivida questo URL contenente i token, quindi continua a mostrare i token su localStorage .
Ho raccolto da questo articolo su Stormpath che localStorage non è la più grande delle idee, dal momento che è vulnerabile all'XSS (qualsiasi JS eseguito arbitrariamente sulla stessa pagina può leggere il token da localStorage ).
Quindi sostengono di usare i cookie solo HTTP per memorizzare i token. In questo approccio, l'API auth reindirizza l'utente all'app con le intestazioni per impostare i cookie solo HTTP con:
-
access_token -
id_token -
csrf_token
Questi cookie sono impostati sul server API auth. L'interfaccia utente dovrebbe anche conoscere il valore di csrf_token . Se l'autenticazione è avvenuta con una richiesta AJAX, potremmo inviarla in un'intestazione; nel caso di OpenID, in cui l'app reindirizzata al dominio API, dovremmo utilizzare l'approccio script e inviarlo nell'hash per l'interfaccia utente dell'app per riceverlo. A quanto ho capito, questi approcci sono approssimativamente equivalenti in termini di sicurezza - sia letti dall'hash o da un'intestazione, in entrambi i casi il browser deve memorizzare questo token CSRF per inviarlo nelle richieste successive .
Il servizio HTTP di Angular gestisce il precedente approccio (intestazione) afferrando il token e salvandolo in un cookie sul dominio dell'interfaccia utente. Quindi invia automaticamente richieste all'API di autenticazione con X-XSRF-Token impostato su quel valore che ha memorizzato nel cookie. Quindi l'API può confermare che questo token dato corrisponde a quello nel suo cookie csrf_token e determinare se l'utente ha inviato questa richiesta.
Questo è molto più complicato dell'approccio localStorage . L'articolo propone che questo è più sicuro perché localStorage è vulnerabile a XSS: un utente malintenzionato che incorpora JS dannoso su una pagina del dominio dell'interfaccia utente può rubare i valori di localStorage . (Ovviamente l'XSS può essere mitigato, ma ci sono certamente situazioni che possono sorgere laddove potremmo essere vulnerabili a XSS, come un CDN in cui l'interfaccia utente viene hackerata e invia script maligni o semplicemente un pacchetto npm che appare benigno e viene utilizzato nell'interfaccia utente ma segretamente cattura localStorage in background.)
Ma in che modo questo approccio CSRF è più sicuro? Dopo tutto, il token CSRF deve essere memorizzato in un cookie sull'interfaccia utente e non può essere un cookie solo HTTP, poiché le richieste all'API devono includere il token in un'intestazione. Quindi non significherebbe la stessa vulnerabilità XSS? Lo script dannoso potrebbe leggere il cookie CSRF sull'interfaccia utente e iniziare a inviare richieste all'API che lo utilizza.
Mi sto perdendo qualcosa qui? In che modo il cookie CSRF è più sicuro rispetto al mettere un token in localStorage , se in entrambi i casi, il mezzo principale di autenticazione con l'API auth può essere letto dal client?