Il bisogno di token portabili
Le applicazioni web moderne necessitano di un meccanismo stateless per trasportare identità e claims: un utente autentica, il server emette un token che il client presenta ad ogni richiesta; API verifica il token senza consultare DB. Deve essere firmabile, verificabile, compatto, URL-safe.
Il rilascio
RFC 7519 (JWT) è pubblicato dall’IETF nel maggio 2015. Editor: Michael B. Jones (Microsoft), John Bradley, Nat Sakimura. Parte del family JOSE (JSON Object Signing and Encryption):
- RFC 7515 — JWS (Web Signature)
- RFC 7516 — JWE (Web Encryption)
- RFC 7517 — JWK (Web Key)
- RFC 7518 — JWA (Web Algorithms)
- RFC 7519 — JWT
Formato
Un JWT è una stringa composta da 3 parti base64url-encoded separate da punti:
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiQWRhIn0.SflKxwRJSMeKKF2...
↓ decoded
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"123","name":"Ada","exp":1735689600}
Signature: HMAC-SHA256(base64url(header).base64url(payload), secret)Claims
- Registrati —
iss(issuer),sub(subject),aud(audience),exp(expiration),nbf(not before),iat(issued at),jti(unique id) - Custom — qualsiasi campo JSON
Algoritmi
- HS256/384/512 — HMAC simmetrico
- RS256/384/512 — RSA asimmetrico (comune in OIDC)
- ES256/384/512 — ECDSA su curve ellittiche
- EdDSA — Ed25519 (più moderno)
- PS256/384/512 — RSA-PSS
- none — vulnerabilità storica, da rifiutare sempre
Vulnerabilità comuni
- Alg confusion —
noneacceptance,RS256 → HS256con public key come HMAC secret - Weak secrets — HMAC con password debole
- No expiration — token validi per sempre
- Sensitive payload — JWT firmato ma non crittografato è leggibile; PII nel payload pericoloso
- No revocation — stateless = difficile revocare prima di expiration
Uso tipico
- OpenID Connect —
id_tokenè un JWT - OAuth 2.0 — access token spesso JWT
- API stateless — bearer token in
Authorization: Bearer <jwt> - SSO federato — asserzioni tra domini
- Short-lived signed URLs
Best practice 2026
- Access token corti (5-15 min), refresh token longer
- Firma asimmetrica (RS256/EdDSA) per micro-servizi
- JWKS rotation — chiavi pubbliche pubblicate con
kid - Non mettere PII nel payload
- Rejettare
alg: noneesplicitamente - Per sessione web, considerare cookie session opachi (più sicuri di JWT in localStorage)
Nel contesto italiano
JWT è fondamento di:
- SPID/CIE — parti dei flussi
- API PA digitale — PagoPA, ANPR, INPS
- SaaS italiani B2B — autenticazione API REST
- Banking API PSD2 — stato stateless sessioni
Riferimenti: RFC 7519 (maggio 2015). IETF JOSE working group. Michael B. Jones, John Bradley, Nat Sakimura. Format header.payload.signature base64url. Algoritmi HS256, RS256, ES256, EdDSA. Famiglia RFC 7515-7519 JOSE.