JWS

JWS (JSON Web Signature, RFC 7515) è il framework di firma crittografica su cui è costruito JWT. Un JWS ha tre parti unite da punti: intestazione.payload.firma, ogni segmento codificato in base64url. L’intestazione è JSON che dichiara l’algoritmo; il payload può essere qualsiasi byte (tipicamente ma non necessariamente JSON); la firma è calcolata sull’intestazione e il payload uniti da un punto usando l’algoritmo e la chiave dichiarati nell’intestazione.

La relazione con JWT: ogni JWT è un JWS il cui payload deve essere un oggetto JSON di claim. Ma JWS stesso è più generale — il payload può essere binario grezzo, un documento XML o qualsiasi altra stringa di byte. Quando vedi un token separato da punti a tre parti che non decodifica base64 in JSON nel segmento centrale, è un JWS, non un JWT.

Algoritmi comuni: HS256 (HMAC-SHA256, chiave simmetrica), RS256 (RSA-SHA256, asimmetrico), ES256 (ECDSA-P256-SHA256, asimmetrico). Il pericoloso algoritmo “none” significa “nessuna firma” — lecito secondo la specifica ma da rifiutare sempre lato server. I verificatori in produzione dovrebbero anche controllare esplicitamente che l’algoritmo dichiarato nell’intestazione corrisponda all’algoritmo atteso per la chiave.

JWS ha due serializzazioni: compatta (il formato separato da punti che JWT usa) e JSON (un envelope JSON che racchiude le stesse tre parti, supportando più firme). La forma compatta è quella usata da quasi tutte le API; la forma JSON è rara al di fuori di protocolli specifici.

Esempio pratico

Prendi il JWS eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9.4Adcj3UFYzPUVaHwte4eBI6vsjOvpz0yiwIM0F7sjuk. Decodifica l’intestazione (primo segmento): {"alg":"HS256"} — firma HMAC-SHA256. Decodifica il payload (secondo segmento): {"sub":"user_123"}. La firma (terzo segmento) è HMAC-SHA256 di eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9 usando la chiave segreta condivisa. Il verificatore ricostruisce l’HMAC e lo confronta usando un confronto a tempo costante; discrepanza → rifiuto. Confronta ora con RS256: stessa struttura, ma la firma è RSA-SHA256, l’emettitore firma con una chiave privata e i verificatori controllano con la chiave pubblica. I byte del token sono più lunghi (le firme RSA sono ~342 caratteri base64 per una chiave a 2048 bit vs 43 per HMAC-SHA256) ma la semantica di validazione è identica dal punto di vista del chiamante.

Quando e perché è importante

JWS è importante ogni volta che un servizio emette, trasmette o accetta un JWT — il che nel 2026 significa la maggior parte delle API. Gli errori che hanno prodotto ripetutamente CVE nell’ultimo decennio: (1) non validare affatto la firma, trattando il payload come fidato solo perché si è analizzato come JSON; (2) accettare alg: none, che rimuove del tutto la firma; (3) accettare qualsiasi algoritmo dichiarato dal token, abilitando l’attacco di confusione HS256-con-chiave-pubblica-RSA; (4) non validare exp, consentendo la riproduzione di token scaduti da tempo; (5) non validare iss e aud, accettando token emessi per servizi completamente diversi. La baseline difensiva: blocca l’algoritmo atteso nella chiamata di verifica, recupera la chiave di verifica da una fonte trusted (tipicamente un URL JWKS in whitelist al momento della configurazione, non il jku del token stesso), e valida exp, iss e aud come controlli separati dopo la firma. Riferimento: RFC 8725 — JWT Best Current Practices.

Perché l’attacco di confusione degli algoritmi continua ad apparire nei CVE: una famiglia di vulnerabilità JWS di lunga data coinvolge un server che chiede alla libreria JWT “questo token è valido?” e lascia che la libreria scelga l’algoritmo di verifica dall’intestazione del token stesso. Un attaccante che conosce la chiave pubblica RSA del server (che, per definizione, è pubblica) può creare un token firmato con HMAC-SHA256 usando i byte della chiave pubblica RSA come segreto HMAC, impostare alg: HS256 nell’intestazione, e molte librerie lo verificheranno. La mitigazione è bloccare la verifica all’algoritmo che ci si aspetta — passarlo come argomento esplicito alla chiamata di verifica invece di lasciare che sia il token a nominarlo. La divulgazione del 2015 contro diverse librerie principali (il jsonwebtoken di Node, il pyjwt di Python, diverse implementazioni Java) è il caso di studio standard.

JWS con payload staccato — quando il payload è troppo grande da incorporare: RFC 7797 definisce una modalità di “payload staccato” in cui il segmento centrale è vuoto e il payload viene trasmesso fuori banda (ad es. come corpo HTTP, mentre il JWS si trova in un’intestazione). È così che alcune API finanziarie firmano corpi di richiesta di grandi dimensioni senza ricodificare in base64 megabyte di JSON. La firma è ancora calcolata sui byte originali del payload; cambia solo il formato wire. Riferimento: RFC 7515 — JSON Web Signature.