Ho letto alcuni post su "JWT vs Cookie" ma mi hanno solo reso più confuso ...

1. Voglio qualche chiarimento , quando si parla di "autenticazione basata su token vs cookie", i cookie qui si riferiscono semplicemente ai cookie di sessione ? La mia comprensione è che il cookie è come un mezzo , può essere utilizzato per implementare un'autenticazione basata su token (memorizzare qualcosa che può identificare l'utente connesso sul lato client ) o un'autenticazione basata sulla sessione (memorizzare una costante sul lato client che corrisponde alle informazioni sulla sessione sul lato server )

2. Perché abbiamo bisogno del token web JSON ? Stavo utilizzando il cookie standard per implementare l'autenticazione basata su token ( non utilizzando l'ID di sessione, non utilizzare la memoria del server o l'archiviazione di file ): Set-Cookie: user=innocent; preferred-color=azuree l'unica differenza che ho notato è che JWT contiene sia il payload che la firma ... mentre puoi scegliere tra cookie firmato o in chiaro per l'intestazione http. Secondo me il cookie firmato ( cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM') è più efficiente in termini di spazio, l'unico inconveniente è che il client non può leggere il token, solo il server può ... ma penso che vada bene perché proprio come il reclamo in JWT è opzionale, non è necessario per il token essere significativo

La più grande differenza tra i token di portatore e i cookie è che il browser invierà automaticamente i cookie , dove i token di portatore devono essere aggiunti esplicitamente alla richiesta HTTP.

Questa funzione rende i cookie un buon modo per proteggere i siti Web, in cui un utente accede e naviga tra le pagine utilizzando i collegamenti.

Il browser che invia automaticamente i cookie ha anche un grande svantaggio, ovvero gli attacchi CSRF . In un attacco CSRF, un sito Web dannoso sfrutta il fatto che il browser allegherà automaticamente i cookie di autenticazione alle richieste a quel dominio e induce il browser a eseguire una richiesta.

Supponiamo che il sito Web all'indirizzo https://www.example.com consenta agli utenti autenticati di modificare le proprie password POSTinserendo la nuova password in https://www.example.com/changepassword senza richiedere la pubblicazione del nome utente o della vecchia password.

Se si è ancora connessi a quel sito Web quando si visita un sito Web dannoso che carica una pagina nel browser che attiva un POST a quell'indirizzo, il browser allegherà fedelmente i cookie di autenticazione, consentendo all'autore dell'attacco di modificare la password.

I cookie possono essere utilizzati anche per proteggere i servizi web, ma oggigiorno vengono utilizzati più spesso i bearer token. Se utilizzi i cookie per proteggere il tuo servizio web, tale servizio deve risiedere nel dominio per il quale sono impostati i cookie di autenticazione, poiché il criterio della stessa origine non invierà i cookie a un altro dominio.

Inoltre, i cookie rendono più difficile per le applicazioni non basate su browser (come le app da mobile a tablet) utilizzare la tua API.

Panoramica

Quello che stai chiedendo è la differenza tra cookie e token di connessione per l'invio di token Web JSON (JWT) dal client al server.

Sia i cookie che i token al portatore inviano dati.

Una differenza è che i cookie servono per inviare e memorizzare dati arbitrari, mentre i token al portatore servono specificamente per inviare dati di autorizzazione.

Questi dati sono spesso codificati come JWT.

biscotto

Un cookie è una coppia nome-valore, che viene memorizzata in un browser web e che ha una data di scadenza e un dominio associato.

Memorizziamo i cookie in un browser Web con JavaScript o con un'intestazione di risposta HTTP.

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

Il browser web invia automaticamente i cookie ad ogni richiesta al dominio del cookie.

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

Token al portatore

Un token portante è un valore che va Authorizationnell'intestazione di qualsiasi richiesta HTTP. Non viene memorizzato automaticamente da nessuna parte, non ha data di scadenza e nessun dominio associato. È solo un valore. Memorizziamo manualmente quel valore nei nostri client e aggiungiamo manualmente quel valore all'intestazione di autorizzazione HTTP.

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

JWT e autenticazione basata su token

Quando eseguiamo l'autenticazione basata su token, come OpenID, OAuth o OpenID Connect, riceviamo un access_token (e talvolta id_token) da un'autorità attendibile. Di solito vogliamo memorizzarlo e inviarlo insieme alle richieste HTTP per le risorse protette. Come lo facciamo?

L'opzione 1 è memorizzare i token in un cookie. Questo gestisce l'archiviazione e invia automaticamente i token al server Cookienell'intestazione di ogni richiesta. Il server quindi analizza il cookie, controlla i token e risponde di conseguenza.

Un'altra opzione è memorizzare il token nella memoria locale / di sessione, quindi impostare manualmente l' Authorizationintestazione di ogni richiesta. In questo caso, il server legge l'intestazione e procede proprio come con un cookie.

Vale la pena leggere le RFC collegate per saperne di più.

Oltre a quanto affermato da MvdD sull'invio automatico dei cookie:

1. Un cookie può essere un mezzo, ma la sua funzione più significativa è il modo in cui interagisce con il browser. I cookie sono impostati dal server e inviati nelle richieste in modi molto specifici. JWT d'altra parte è esclusivamente un mezzo, è un'affermazione di alcuni fatti in una particolare struttura. Se fossi così incline, potresti mettere un JWT come cookie di autenticazione. Quando si leggono articoli che li confrontano, in genere si parla di utilizzare un JWT inviato come token di portatore dal codice front-end rispetto a un cookie di autenticazione che corrisponde a una sessione memorizzata nella cache o ai dati dell'utente sul back-end.
2. JWT offre molte funzionalità e le inserisce in uno standard in modo che possano essere utilizzate tra le parti. Un JWT può agire come un'affermazione firmata di alcuni fatti in molti luoghi diversi. Un cookie, indipendentemente dai dati che inserisci o se lo firmi, ha senso solo per essere utilizzato tra un browser e un back-end specifico. JWT può essere utilizzato dal browser al back-end, tra back-end controllati da parti diverse (OpenId Connect è un esempio) o all'interno dei servizi di back-end di una parte. Per quanto riguarda il tuo esempio specifico dei tuoi cookie firmati, puoi probabilmente ottenere le stesse funzioni ("non utilizzare l'ID di sessione, non utilizzare la memoria del server o l'archiviazione di file") di JWT in quel caso d'uso, ma perdi le librerie e la revisione tra pari di lo standard, oltre alle questioni CSRF di cui si è parlato nell'altra risposta.

In sintesi: i post che stai leggendo stanno probabilmente confrontando JWT come token di trasporto con il cookie di autenticazione per il browser per scopi di autenticazione del server. Ma JWT può fare molto di più, porta standardizzazione e funzionalità per l'uso al di fuori del caso d'uso a cui probabilmente stai pensando.

Sebbene i cookie possano aumentare il rischio di attacchi CSRF in virtù del fatto che vengono inviati automaticamente insieme alle richieste, possono diminuire il rischio di attacchi XSS quando il HttpOnlyflag è impostato, perché qualsiasi script inserito nella pagina non sarà in grado di leggere il biscotto.

CSRF: un utente fa clic su un collegamento (o visualizza immagini) sul sito di un utente malintenzionato, il che fa sì che il browser invii una richiesta al sito della vittima. Se la vittima utilizza i cookie, il browser includerà automaticamente il cookie nella richiesta e se la richiesta GET può causare azioni non di sola lettura, il sito della vittima è vulnerabile all'attacco.

XSS: un utente malintenzionato incorpora uno script nel sito della vittima (il sito della vittima è vulnerabile solo se gli input non vengono disinfettati correttamente) e lo script dell'aggressore può fare tutto ciò che javascript è autorizzato a fare sulla pagina. Se archivi i token JWT nella memoria locale, lo script dell'aggressore potrebbe leggere quei token e anche inviarli a un server che controlla. Se utilizzi i cookie con il HttpOnlyflag, lo script dell'aggressore non sarà in grado di leggere il tuo cookie per cominciare. Detto questo, lo script che hanno inserito con successo sarà ancora in grado di fare tutto ciò che javascript può fare, quindi sei ancora imbrogliato IMO (cioè, anche se potrebbero non essere in grado di leggere il cookie per inviarlo al proprio server per un uso successivo , possono inviare richieste al sito vicitim utilizzando XHR, che includerà comunque il cookie).

Rif: Necessità di token Web JSON

Biscotti

In caso di cookie, una volta che l'utente è stato autenticato, il server Gmail creerà un ID di sessione univoco. Corrispondendo a questo id di sessione salverà in memoria tutte le informazioni sull'utente che sono necessarie al server Gmail per riconoscere l'utente e consentirgli di eseguire le operazioni.
Inoltre, per tutte le successive richieste e risposte, verrà passato anche questo ID di sessione. Quindi ora quando il server riceve una richiesta controllerà l'id della sessione. L'utilizzo di questo ID di sessione controllerà se sono presenti informazioni corrispondenti. Quindi consentirà all'utente di accedere alla risorsa e restituire la risposta insieme all'ID di sessione.

Inconvenienti dei cookie

• I cookie / ID sessione non sono autonomi. È un token di riferimento. Durante ogni convalida, il server Gmail deve recuperare le informazioni ad esso corrispondenti.
• Non adatto per l'architettura di microservizi che coinvolge più API e server

JWT

• JWT è autonomo. È un segno di valore. Quindi durante ogni convalida il server Gmail non ha bisogno di recuperare le informazioni ad esso corrispondenti.
• È firmato digitalmente, quindi se qualcuno lo modifica il server lo saprà
• È più adatto per l'architettura dei microservizi
• Presenta altri vantaggi come specificare l'ora di scadenza.