cookie vs. sessione vs jwt

Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles)

I cookie sono tuple key-value originariamente indirizzate a conservare i dati relativi all'attività del cliente. Questa conservazione è ciò che conosciamo come sessione o stato dell'applicazione . Fondamentalmente, sono stati creati per mantenere lo stato delle applicazioni web; e più specificamente, per mantenere lo stato sul lato client. ⁽¹⁾

I cookie vengono solitamente impostati dal server tramite le intestazioni di risposta ( Set-Cookie key=value ). Tuttavia, possono essere impostati anche dal client. Ad esempio, per DOM ( document.cookie ).

Una cosa importante da sapere sui cookie è che non identificano gli utenti. Piuttosto associano il terna data - client - server / percorso . ⁽³⁾

Utilizziamo i cookie con i file perché, durante i primi giorni dei browser web, questi dovevano persistere i cookie in qualche modo, essendo i file il supporto più fattibile. I browser di oggi memorizzano i cookie (tra le altre cose) in archivi locali (DB incorporati).

Session: only the unique client id is sent in a file (also called cookie), everything else is stored on the server.

Per sessione, suppongo tu intenda sessioni del server . Come ho commentato, le sessioni possono essere implementate anche dal lato client. La differenza con le sessioni lato client è che i dati vengono archiviati da qualche parte sul lato server. ⁽²⁾ In tali ambienti, ciò che otteniamo è un id di sessione; e lo otteniamo in forma di cookie. Senza l'id di sessione, il server non sarebbe in grado di correlare le richieste in arrivo con l'attività precedente del client. (3) Ad esempio, l'utente autenticato, il carrello acquisti, ecc.

In ogni caso, un ID di sessione non identifica necessariamente un utente. Associa uno stato di applicazione specifico con un client Web. Le sessioni potrebbero o potrebbero non contenere dati utente.

Nelle appllicazioni distribuite, la sessione dovrebbe essere serializzabile per ovvi motivi. Se sono memorizzati, la memoria in memoria (componente) dovrebbe essere serializzabile. Una soluzione comune è memorizzare le sessioni nei file. O in NoSQL DB come Redis.

Riguardo alla sicurezza. Le sessioni sul lato server sono più sicure rispetto al lato client. I client sono più vulnerabili alle minacce perché gli utenti di solito non sono seriamente consapevoli della sicurezza. Almeno non l'utente normale.

D'altra parte, attaccare l'infrastruttura lato server non è trival.

JWT: everything is stored in the token (which could also be stored in a text file, which is also called cookie)

Non proprio. JWT memorizza i dati principalmente relativi all'autorizzazione e all'emittente.

Sebbene utilizzino per contenere l'ID utente, troviamo JWT che non identificano gli utenti autenticati. Ad esempio, token per le sessioni degli ospiti. Il contenuto principale dei JWT è claims ; elementi da controllare con il processo di autorizzazione.

È importante tenere presente che le JWT non sono archivi globali . La sessione o lo stato dell'applicazione devono ancora essere memorizzati da qualche parte e gestiti in modo indipendente.

Riguardo ai JWT, questi sono spesso memorizzati come cookie, sebbene possano essere memorizzati anche in archivi locali. Inoltre, La community OWASP considera sessionStorage più sicuro per i browser web. Tuttavia, dipende dalla versione del browser .

1: Il World Wide Web è pensato per essere apolidi. Se vogliamo creare applicazioni lato server stateless, le sessioni dovrebbero essere archiviate da qualche parte sul lato client.

2: Trasformare l'applicazione lato server in un'applicazione stateful .

3: Client come applicazione, non come utente.

Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles)

La tua definizione di cookie in realtà non descrive quello che fanno. Un cookie è una coppia chiave-valore che viene impostata tramite l'intestazione di risposta HTTP ( Set-Cookie ) dal server e memorizzata dai client che li supportano. I cookie vengono rispediti con ogni richiesta successiva (nell'intestazione Cookie ) per le richieste che corrispondono a schema, host, percorso, https mentre il cookie non è scaduto. Puoi memorizzare tutto ciò che vuoi in un cookie e ti consente di supportare lo stato sul protocollo stateless di HTTP.

Un esempio di scambio di cookie è simile a questo:

Session: only the unique client id is sent in a file (also called cookie), everything else is stored on the server

Questo è giusto. Una sessione è dati che vengono archiviati sul lato server della sessione corrente di un utente. Per fare in modo che funzioni in un protocollo stateless come HTTP, l'utente deve inviare il proprio ID di sessione ad ogni richiesta, in modo che il server possa recuperare la sessione corretta per l'utente. L'ID di sessione è in genere memorizzato in un cookie (vedi sopra). Questo non è un cookie diverso da qualsiasi altro cookie, i dati sono solo l'ID del server per la sessione utente.

JWT: everything is stored in the token (which could also be stored in a text file, which is also called cookie)

È praticamente vero. Tutto è memorizzato nel token. Il token può essere memorizzato in un cookie (vedi sopra). Questa è un'alternativa alle sessioni del server, e funziona perché il token è firmato e verificato dal server, quindi non può essere alterato o modificato, ed è sicuro da memorizzare sul lato client.