Struttura del Token JWT Spiegata: Header, Payload e Signature
Struttura del Token JWT Spiegata
Ogni JSON Web Token (JWT) è una stringa compatta e sicura per URL che trasporta claim tra due parti. Comprenderne la struttura interna è essenziale per qualsiasi sviluppatore che lavori con la sicurezza basata su token.
Le Tre Parti di un JWT
Un JWT è composto da tre parti separate da punti (.):
header.payload.signature
Esempio:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Ogni parte è JSON codificato in base64url. Un JWT è firmato, non cifrato: chiunque può decodificarlo e leggerne il contenuto.
Parte 1: L'Header
L'header contiene metadati sul token: l'algoritmo di firma e il tipo di token.
| Campo | Descrizione | Valori di Esempio |
|-------|-------------|-------------------|
| alg | Algoritmo di firma (obbligatorio) | HS256, RS256, ES256 |
| typ | Tipo di token (opzionale) | JWT |
| kid | ID della chiave (opzionale) | "key-1" |
{
"alg": "HS256",
"typ": "JWT"
}
Il campo alg indica al verificatore quale algoritmo ha creato la firma. Una mancata corrispondenza dell'algoritmo — o l'accettazione di alg: "none" — è una vulnerabilità di sicurezza JWT comune.
Parte 2: Il Payload
Il payload contiene claim sull'utente e metadati. I claim rientrano in tre categorie:
Claim Registrati
| Claim | Nome Completo | Scopo |
|-------|---------------|-------|
| iss | Issuer | Chi ha emesso il token |
| sub | Subject | Identifica l'utente |
| aud | Audience | Destinatario previsto |
| exp | Expiration | Timestamp di scadenza del token |
| nbf | Not Before | Token non valido prima di questo momento |
| iat | Issued At | Timestamp di creazione del token |
| jti | JWT ID | Identificatore univoco del token |
Esempio di Payload Decodificato
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022,
"exp": 1516242622,
"iss": "https://auth.example.com"
}
I claim pubblici sono definiti nel registro IANA o utilizzano URI resistenti alle collisioni. I claim privati sono claim personalizzati concordati tra emittente e consumatore.
Parte 3: La Signature
La firma viene creata combinando l'header codificato, il payload codificato e una chiave segreta utilizzando l'algoritmo dell'header. Serve a due scopi:
- Integrità — conferma che il token non è stato modificato dopo la firma.
- Autenticazione — dimostra che il token è stato firmato dalla parte prevista.
Creazione della Firma HS256
HMACSHA256(
base64urlEncode(header) + "." + base64urlEncode(payload),
secret
)
Creazione della Firma RS256
RSASHA256(
base64urlEncode(header) + "." + base64urlEncode(payload),
privateKey
)
Base64url vs Base64 Standard
| Aspetto | Base64 Standard | Base64url |
|---------|-----------------|-----------|
| Carattere 62 | + | - |
| Carattere 63 | / | _ |
| Padding | = | Omesso |
Questa codifica garantisce che i JWT siano sicuri per gli header HTTP, i parametri di query e i percorsi URL senza bisogno di percent-encoding.
Processo Completo di Creazione di un JWT
- Crea il JSON dell'header e codificalo in base64url.
- Crea il JSON del payload e codificalo in base64url.
- Concatena con un separatore
.. - Firma con l'algoritmo scelto e la chiave segreta.
- Codifica la firma in base64url.
- Concatena tutte e tre le parti con separatori
..
Considerazioni sulla Sicurezza
- Non conservare mai segreti nel payload. Il payload è codificato, non cifrato.
- Valida sempre la firma. Senza verifica, chiunque può falsificare i token.
- Controlla l'header
alg. Rifiutaalg: "none"e i tentativi di downgrade dell'algoritmo. - Imposta tempi di scadenza brevi. Usa claim
expin minuti o ore, non in mesi.
Decodifica un Token JWT Online
Usa lo strumento decoder JWT per esaminare qualsiasi token. Incollalo e vedi immediatamente header, payload e algoritmo di firma decodificati. Tutta l'elaborazione avviene nel tuo browser.