Cookie: nella loro versione iniziale, un file di testo con un ID client univoco e tutte le altre informazioni necessarie sul client (ad es. Ruoli)
I cookie sono tuple key-valueoriginariamente indirizzate a conservare i dati relativi all'attività del cliente. Questa conservazione è ciò che conosciamo come stato della sessione o dell'applicazione . Fondamentalmente, sono stati creati per mantenere lo stato delle applicazioni web; più specificamente, lo stato sul lato client. (1)
I cookie vengono generalmente impostati dal server tramite le intestazioni di risposta ( Set-Cookie key=value). Tuttavia, possono essere impostati anche dal client. Ad esempio, da DOM ( document.cookie).
Una cosa importante da sapere sui cookie è che non identificano gli utenti. Piuttosto associano i dati terna - client - server / percorso . (3)
Di solito associamo i cookie ai file perché durante i primi giorni dei browser Web 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).
Sessione: solo un ID client univoco viene inviato in un file (chiamato anche cookie), tutto il resto viene archiviato sul server.
Per sessione, immagino che intendi sessioni server . Come ho commentato, le sessioni possono essere implementate anche sul lato client. La differenza con le sessioni lato client è che i dati vengono archiviati da qualche parte sul lato server. (2) In tali scenari, ciò che otteniamo è un ID di sessione; e lo otteniamo sotto forma di cookie. Senza l'id di sessione, il server non sarebbe in grado di correlare le richieste in entrata con l'attività precedente del client. (3) Ad esempio l'utente autenticato, il carrello, ecc.
In ogni caso, un ID sessione non identifica necessariamente un utente. Associa uno stato specifico dell'applicazione a un client Web. Le sessioni potrebbero contenere o meno i dati dell'utente.
Nelle applicazioni distribuite, la sessione dovrebbe essere serializzabile per ovvi motivi. Se sono archiviati in memoria, l'archiviazione in memoria (componente) deve essere serializzabile. Una soluzione comune è quella di archiviare sessioni in file. O in NoSQL DB come Redis.
Per quanto riguarda la sicurezza. Le sessioni sul lato server sono più sicure rispetto al lato client. I clienti sono più vulnerabili alle minacce perché gli utenti di solito non sono consapevoli delle tante minacce a cui sono esposti. Almeno non l'utente normale.
D'altra parte, attaccare un'infrastruttura sul lato server non è una cosa di sorta.
JWT: tutto è memorizzato nel token (che potrebbe anche essere memorizzato in un file di testo, che è anche chiamato cookie)
Non proprio. JWT archivia i dati principalmente relativi all'autorizzazione e all'emittente del token.
Sebbene utilizzino per contenere l'ID utente (sotto), troviamo JWT che non identificano gli utenti autenticati. Ad esempio, token per le sessioni degli ospiti. Il contenuto principale dei JWT sono i reclami ; articoli da verificare tramite il processo di autorizzazione.
È importante tenere presente che i JWT non sono archivi globali . La sessione o lo stato dell'applicazione deve ancora essere archiviato da qualche parte e gestito in modo indipendente.
Per quanto riguarda i JWT, questi sono spesso memorizzati come cookie, sebbene possano essere memorizzati anche in archivi locali. Inoltre, la comunità OWASP considera sessionStorage il più sicuro per i browser web. Tuttavia, dipende dalla versione del browser .
1: Il World Wide Web è pensato per essere apolide. Se vogliamo creare applicazioni lato server senza stato, le sessioni dovrebbero essere archiviate da qualche parte nel lato client.
2: trasformazione dell'applicazione lato server in un'applicazione con stato .
3: client come applicazione, non come utente.
user_ida un utente che ha effettuato l'accesso.