JWT — Cheat Sheet

Tag: jwt, authentication, authorization, security, backend, tokens, rest-api

Livello: intermedio

TL;DR: Standard compatto e stateless per trasferire claim crittograficamente firmati tra client e server tramite Header, Payload e Signature.

Concetti chiave

Formato composto da tre parti Base64Url separate da punti: Header, Payload, Signature.

L'Header definisce il tipo di token e l'algoritmo di firma crittografica usato (es. HS256, RS256).

Il Payload contiene i claim: registrati (iss, exp, sub), pubblici o personalizzati di dominio.

I dati nel Payload sono solo codificati in Base64Url, non cifrati: chiunque puo' leggerne il contenuto.

Autenticazione stateless: il server valida la firma senza dover interrogare un database di sessione.

Algoritmi simmetrici (HMAC con secret condiviso) contro asimmetrici (chiave privata firma, chiave pubblica valida).

Viene trasmesso tipicamente nell'header HTTP Authorization: Bearer <token>.

Durata limitata: l'access token ha scadenza breve, combinato con un refresh token per il rinnovo.

Domande tipiche e risposte pronte

Q: Qual e' la differenza tra un token simmetrico e uno asimmetrico in JWT?R: Con HMAC (HS256) la stessa chiave segreta firma e verifica, richiedendo fiducia totale tra i servizi. Con algoritmi asimmetrici (RS256) firmo con la chiave privata nel server di auth e distribuisco la chiave pubblica per la sola validazione.

Q: Come gestisci la revoca di un JWT prima della sua scadenza naturale?R: Tengo la durata dell'access token molto breve e gestisco la revoca sul refresh token a database, oppure uso una blacklist in-memory (es. Redis) per gli access token invalidati prima di exp.

Q: Possiamo salvare dati sensibili come password o carte di credito nel Payload JWT?R: No, il payload e' codificato in Base64Url e leggibile in chiaro da chiunque intercetti o possieda la stringa, a meno di cifratura JWE.

Insidie e errori comuni

Vulnerabilita' dell'algoritmo none: accettare token privi di firma senza validazione server-side.

Confusione tra chiavi asimmetriche e simmetriche: validare un token RS256 usando la chiave pubblica come secret HMAC.

Inserimento di dati sensibili nel Payload scambiando la firma crittografica per crittografia dei dati.

Durata di validita' (exp) troppo lunga senza un meccanismo centralizzato di invalidazione.

Mancata verifica rigorosa dei claim standard exp, iss (issuer) e aud (audience).

Snippet e comandiTypeScript

```import jwt from 'jsonwebtoken';

// Generazione token con firma asimmetrica o simmetrica

const token = jwt.sign(

{ sub: user.id, role: user.role },

process.env.JWT_SECRET as string,

{ algorithm: 'HS256', expiresIn: '15m' }

);

// Verifica e decodifica sicura

try {

const decoded = jwt.verify(token, process.env.JWT_SECRET as string, {

algorithms: ['HS256'],

});

} catch (err) {

// Token scaduto o firma non valida

}

```

Da ripassare

[ ] Meccanismo di rotazione dei refresh token e prevenzione del riuso

[ ] Differenza architetturale tra JSON Web Signature (JWS) e JSON Web Encryption (JWE)

[ ] Pattern di conservazione client-side: HttpOnly Cookie vs Web Storage (XSS vs CSRF)

[x] Struttura Header, Payload, Signature e codifica Base64Url