Decoder JWT

Anatomia di un JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNjAwMDAwMDAwfQ
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Ogni segmento è codificato in base64url (non standard base64). L’intestazione è JSON come {"alg":"HS256","typ":"JWT"}, il payload è JSON come {"sub":"1234567890","name":"Alice","iat":1600000000}, e la firma è la firma HMAC o RSA di intestazione.payload.

Claim standard (RFC 7519)

Algoritmi supportati

Il pericolo del alg: none

Le prime librerie JWT consentivano token "alg": "none" e li accettavano ingenuamente come validi. Sempre:

• Inserisci nella whitelist gli algoritmi che la tua applicazione accetta.
• Rifiuta alg: none incondizionatamente.
• Rifiuta alg: HS256 quando il tuo codice di verifica si aspetta RS256 (l’attacco di “confusione dell’algoritmo”).

Cosa NON è un JWT

• Non crittografato. L’intestazione e il payload sono codificati in base64, il che è facilmente decodificabile. Non mettere segreti in un JWT senza avvolgerlo in JWE.
• Non revocabile per impostazione predefinita. Una volta emesso, un JWT è valido fino a exp. Per la revoca hai bisogno di una blacklist o di una scadenza breve + token di aggiornamento.
• Non è un sostituto dei cookie di sessione per ogni caso d’uso. Token opachi memorizzati lato server sono spesso più semplici e sicuri.

Errori comuni

• Fidarsi dell’intestazione. Il kid e alg provengono dal token stesso. Un server compromesso può impostarli arbitrariamente; valida sempre contro un elenco fisso.
• Ignorare la differenza di nbf e iat. La deriva dell’orologio significa che iat > ora può accadere. Consenti un piccolo margine (30-60s).
• Registrare interi JWT. Il payload spesso contiene ID utente, email, permessi, PII che non dovrebbero finire in stdout.
• Usare HS256 con una chiave debole. Una chiave segreta di 16 caratteri è vulnerabile a forza bruta in pochi minuti. Usa almeno 256 bit di entropia casuale.