JWT: come gestire le richieste GET quando l'utente apre una nuova scheda?

Question

Ci sono molti vantaggi quando si usa JWT su Cookie su app basate su API e capisco che è possibile memorizzare il token su sessionStorage quando si accede all'app tramite browser. È possibile impostare un intercettore sul codice JS per iniettare il token JWT sull'intestazione di autorizzazione per le richieste GET, a condizione che queste richieste GET vengano eseguite dallo stesso codice che ha autenticato l'utente.

Ma cosa succede quando l'utente viene autenticato, quindi apre una nuova scheda e tenta di accedere a un'area diversa riservata (o anche alla stessa area) dell'app/sito? In questo caso, non vi è alcun intercettore per iniettare il token nell'intestazione Autorizzazione nella nuova scheda. Suppongo che il server riceverà la richiesta GET, cercherà un token JWT nell'intestazione Autorizzazione e non lo troverà, rifiutando la richiesta.

Quando si utilizzano i cookie, vengono sempre inviati dal browser in modo nativo e non è necessario preoccuparsi di nuove schede e autenticazione.

C'è un modo per impostare l'intestazione Autorizzazione globalmente per il dominio sul browser nel momento in cui l'utente si autentica nella prima scheda? Quali sono le solite soluzioni per questa materia, se ce ne sono?

Answer 1

All'accesso a un URL protetto senza le credenziali corrette (come un JWT) il browser verrebbe reindirizzato a un endpoint specifico (ad esempio sul server di autorizzazione) dove può ottenere un nuovo JWT.

Questo accade per esempio nel flusso implicito OpenID Connect: http://openid.net/specs/openid-connect-implicit-1_0.html

Ma sarebbe anche possibile memorizzare il JWT in un biscotto. Questo non è un modo standardizzato di presentare le JWT, quindi sarebbe specifico per il tuo client/browser e l'applicazione protetta.

Answer 2

Ho deciso di aggiungere un aggiornamento a questa domanda a causa di nuovi risultati. Non cambierò la risposta originale.

In primo luogo, secondo le mie osservazioni sulla risposta originale:

ho finito per usare un cookie per tenere il JWT, ma è impostato dal client utilizzando github.com/js-cookie/js-cookie dopo la prima autenticazione. Il mio codice server verifica il JWT nella richiesta in questo ordine: header, body, cookie. Quindi, ogni volta che l'utente apre una nuova scheda, viene utilizzato il cookie locale. Altre richieste in-page iniettano il JWT in un'intestazione. In questo modo, l'operazione è orientata all'API, ricadendo su un cookie nell'ultimo caso .

Tuttavia, ho anche avuto una preoccupazione per la sicurezza di un cookie generato sul browser. Questo perché, poiché è generato da un client JavaScript, non puoi utilizzare HttpOnly, lasciandolo aperto per XSS.

Soluzione

Dal momento che sto usando Sails, ho deciso di creare un cookie sul server con il token JWT, e inviarlo con la risposta, che contiene anche il token JWT su un oggetto sulla corpo.

http://sailsjs.com/documentation/reference/response-res/res-cookie

res.cookie()

Imposta un cookie con nome (nome) e valore (valore) da inviare insieme a la risposta.

 res.cookie('x-access-token', token, { 
     expires: expire, 
     httpOnly: true 
     }); 
     return res.status(200).json({ 
     "x-access-token" : token 
     }); 

Questo cookie non richiede sessione abilitato sul server, in modo che soddisfa il vantaggio "sessionless" di utilizzo di JWT.

Se il client è un browser, memorizzerà e riutilizzerà il token nelle richieste successive, incluse le nuove schede con l'aiuto del cookie HttpOnly.

Se si tratta di un altro tipo di client, ha il token JWT sul corpo della risposta.