JWE

JWE (JSON Web Encryption, RFC 7516) è il framework di cifratura nella famiglia JOSE (JSON Object Signing and Encryption), fratello di JWS. Dove JWS firma un payload (tenendolo leggibile ma verificabile per la manomissione), JWE cifra il payload (mantenendo riservato il suo contenuto).

Un token JWE in serializzazione compatta ha cinque segmenti separati da punti invece dei tre di JWT:

1. Intestazione — JSON che dichiara gli algoritmi di cifratura.
2. Content Encryption Key (CEK) cifrata — la chiave simmetrica usata per il payload, a sua volta cifrata con la chiave del destinatario.
3. Vettore di Inizializzazione (IV) — nonce casuale per ogni cifratura.
4. Testo cifrato — il payload effettivamente cifrato.
5. Tag di autenticazione — per le modalità AEAD; verifica che il testo cifrato non sia stato manomesso.

JWE usa uno schema ibrido: una chiave simmetrica (il CEK) cifra il payload (perché la crittografia simmetrica è veloce), poi una chiave asimmetrica cifra il CEK (perché quella asimmetrica è l’unico modo per rendere le chiavi scambiabili senza un segreto condiviso). Algoritmi standard: RSA-OAEP per l’avvolgimento della chiave, A256GCM per la cifratura del payload.

Quando usare JWE vs. JWT: la maggior parte dei sistemi di autenticazione usa JWT (firmato ma non cifrato) perché le claim non sono segrete — un token contenente “sub: user_123, exp: ...” va bene da leggere. Usa JWE quando il token contiene payload genuinamente sensibili (cartelle cliniche, dettagli finanziari, dati di routing interni) e non puoi garantire che gli intermediari non lo ispezionino. La maggior parte dei sistemi moderni preferisce tenere i dati sensibili sul server e usare un breve ID di sessione opaco — più semplice di JWE.

Esempio pratico

Un emettitore di token deve inviare un riferimento a una cartella clinica a un servizio downstream tramite il browser, ma il browser non deve poterlo leggere. L’emettitore crea un JWE: intestazione {"alg":"RSA-OAEP-256","enc":"A256GCM","cty":"JWT","kid":"recipient-2026"}, payload {"patient_id":"P-12345","record_id":"R-78910"}. L’emettitore genera un CEK casuale a 256 bit, cifra il payload con AES-256-GCM sotto quella chiave (producendo testo cifrato + tag di autenticazione a 128 bit), e cifra il CEK stesso sotto la chiave pubblica RSA del destinatario. L’output è cinque segmenti codificati in base64url uniti da punti — circa 600-800 byte totali. Il destinatario decodifica in ordine inverso: decifratura RSA del CEK usando la chiave privata, decifratura AES-GCM del payload usando il CEK, verifica che il tag di autenticazione corrisponda. Qualsiasi manomissione di uno dei cinque segmenti fa fallire il controllo del tag di autenticazione e il destinatario rifiuta il token. Il browser che porta nel mezzo il JWE vede solo base64 opaco — gli ID paziente/cartella sono inaccessibili.

Quando e perché è importante

JWE è importante ogni volta che un token deve attraversare intermediari non fidati portando claim riservate — dati dei pazienti, dettagli di routing finanziario, identificatori utente interni — e l’architettura deve usare un token piuttosto che una sessione lato server. L’errore da evitare è ricorrere prima a JWE quando funziona un’architettura più semplice: la maggior parte dei flussi di autenticazione è meglio gestita da JWT firmati contenenti solo riferimenti (un ID utente, un ID di sessione) che gli intermediari possono vedere senza danni, mentre i dati sensibili rimangono nel database dell’emettitore. Usa JWE quando gli intermediari sono operativamente tenuti a detenere il token ma sono contrattualmente o legalmente limitati dal leggerlo — SSO federato tra organizzazioni, scambio di dati sanitari tra fornitori, alcuni flussi open-banking PSD2. Il secondo errore è la scelta errata degli algoritmi: RSA-OAEP con SHA-1 è deprecato, RSA-OAEP-256 è la raccomandazione attuale; A128CBC-HS256 è ancora accettabile ma A256GCM è preferito per i nuovi deployment. Riferimento: RFC 7518 — JSON Web Algorithms.

JOSE annidato — firmare poi cifrare: per i token che necessitano sia di autenticità (origine dimostrabile) che di riservatezza, il pattern standard è firma-poi-cifra: il payload viene prima avvolto in un JWS, poi l’intero JWS diventa il payload di un JWE. Il campo dell’intestazione cty: "JWT" nel JWE esterno segnala al parser che il contenuto decifrato è a sua volta un token JOSE da verificare. L’ordine inverso (cifra poi firma) è meno sicuro perché la firma sarebbe sul testo cifrato che potrebbe essere riprodotto tra destinatari. La maggior parte delle piattaforme SSO aziendali che usano JWE (token di federazione di Microsoft Azure AD, alcune API bancarie) fornisce firma-poi-cifra come standard. Riferimento: RFC 7516 — JSON Web Encryption.