Decodifica, crea e verifica token JWT. Simula scadenze e gestisci header/payload/firma. Tutto nel browser, nessun dato inviato a server.
Un JSON Web Token (JWT) è uno standard aperto (RFC 7519) per trasmettere informazioni verificabili tra sistemi come oggetto JSON compatto e URL-safe. È formato da tre parti separate da punti: Header (algoritmo e tipo di token), Payload (i claim — informazioni sull'utente e metadati), Signature (firma crittografica che garantisce l'integrità). La firma non cifra il payload — chiunque può leggerlo. La firma garantisce solo che il contenuto non è stato modificato dopo l'emissione.
Decoder: decodifica qualsiasi token JWT, mostra header e payload formattati in JSON e indica se il token è scaduto (claim exp nel passato). Verifier: verifica la firma con la chiave segreta — conferma che il token non è stato manomesso. Generator: crea nuovi token firmati con i claim e la chiave che specifichi. Inspector: analizza la sicurezza del token — segnala algoritmi deboli (none, HS256 con chiavi corte), claim mancanti o valori sospetti.
I claim registrati più usati: sub (Subject — identificatore univoco dell'utente), iat (Issued At — timestamp Unix di emissione), exp (Expiration Time — scadenza, in secondi Unix), nbf (Not Before — il token non è valido prima di questa data), iss (Issuer — chi ha emesso il token), aud (Audience — a chi è destinato), jti (JWT ID — identificatore univoco del token, per prevenire replay attack). I claim custom vanno in un namespace (es. https://tuodominio.com/ruolo).
Tutti e tre usano HMAC (Hash-based Message Authentication Code) con una chiave segreta condivisa. La differenza è la lunghezza dell'hash: 256, 384 e 512 bit. HS256 è il default e sufficiente per la maggior parte dei casi. HS512 offre maggiore resistenza a collision attack ma chiavi più lunghe. Alternativa comune: RS256 (RSA con chiave pubblica/privata) — il server firma con la chiave privata, i client verificano con la chiave pubblica senza conoscere il segreto. RS256 è preferibile in architetture microservizi dove più servizi devono verificare i token.
I problemi più frequenti in produzione: token scaduto (exp nel passato) — risposta 401, il client deve fare il refresh; algoritmo "none" — alcuni server vulnerabili accettano token senza firma se l'algoritmo è "none"; segreto troppo corto — chiavi HS256 sotto i 256 bit sono soggette a brute force; payload con dati sensibili — il payload è visibile a chiunque, non mettere password o numeri di carta; mancato refresh — access token con scadenza breve + refresh token long-lived è il pattern corretto.
No. Tutte le operazioni avvengono nel browser con JavaScript puro. Nessun dato — né il token né la chiave segreta — viene trasmesso a server esterni. Puoi usare il tool con token di produzione senza rischi.
Il payload è codificato in Base64url, non cifrato. La firma garantisce l'integrità (che non sia stato modificato), non la confidenzialità (che non possa essere letto). Per trasmettere dati riservati usa JWE (JSON Web Encryption), non JWT standard.
Sì, nella scheda Verifier puoi incollare la chiave segreta (per HS256/384/512) o la chiave pubblica (per RS256) per verificare la firma. Il tool mostra se la firma è valida o se il token è stato manomesso.
Il pattern raccomandato: access token brevi (15-60 minuti) + refresh token long-lived (7-30 giorni) conservato in httpOnly cookie. Access token brevi limitano la finestra di rischio in caso di furto — un token rubato scade presto. I refresh token in httpOnly cookie non sono accessibili da JavaScript (protezione XSS).