JWT (JSON Web Token) is een open standaard gedefinieerd door IETF in RFC 7519 (RFC 7515 beschrijft de JWS signing vorm, RFC 7516 beschrijft JWE encryptie, RFC 7517 definieert JWK sleutels) voor het veilig overdragen van 'beweerde' gebruikersinformatie tussen HTTP verzoeken, OIDC flows en microservice aanroepen. Een standaard JWT string bestaat uit drie Base64URL-gecodeerde segmenten: Header (algoritme en type), Payload (Claims, de gebruikersdata) en Signature (een op sleutel gebaseerde handtekening over de eerste twee). De drie segmenten zijn verbonden met een letterlijke punt `.`, bijv. `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.
**JWT is geen encryptie.** Dit is het meest voorkomende misverstand. De Payload is standaard plaintext — iedereen kan het Base64URL-decoderen en de inhoud lezen. JWT biedt **tamper-evidence**, niet vertrouwelijkheid: de server hertekent Header.Payload met de gedeelde sleutel en vergelijkt met de Signature van het token. Als ze overeenkomen, is het token niet gewijzigd tijdens transport. Dit is de 'treinkaartje met anti-vervalsstempel' metafoor: de inspecteur vraagt of het ticket echt is, niet of de QR-code onleesbaar is.
JWT verdeelt verantwoordelijkheden netjes over 13 algoritmen. **HMAC familie** (HS256/HS384/HS512) gebruikt een symmetrische sleutel voor zowel signing als verifying, snel en eenvoudig, geschikt voor een enkele service of een vertrouwd cluster; de secret moet minstens de digest lengte zijn (bijv. ≥ 32 bytes voor HS256). **RSA familie** (RS256/RS384/RS512) gebruikt RSASSA-PKCS1-v1_5, het meest voorkomende asymmetrische schema — ondertekenaars houden de private sleutel, verifiers houden de publieke sleutel. **RSA-PSS familie** (PS256/PS384/PS512) gebruikt de nieuwere RSA-PSS padding met sterkere beveiligingsgaranties, de voorkeur van AWS SigV4 en moderne OIDC identity providers. **ECDSA familie** (ES256/ES384/ES512) gebruikt elliptische curves (respectievelijk P-256/P-384/P-521) met kortere handtekeningen en betere prestaties. **EdDSA** (voornamelijk Ed25519) is extreem snel en deterministisch (zelfde bericht +zelfde sleutel = dezelfde handtekening elke keer) en is het aanbevolen algoritme in OAuth 2.1 en nieuwe protocollen.
Beveiliging is waar JWT struikelt in productie. De OWASP JWT Cheat Sheet noemt minstens vier harde regels: (1) zet nooit wachtwoorden, nationale ID's, kaartnummers of API keys als plaintext in de Payload; (2) de server moet **nooit het alg veld vertrouwen** dat in de Token Header staat — het moet verifiëren met een hard-coded algoritme, anders omzeilt een aanvaller die de header herschrijft naar `alg: none` alles (dit is de oorzaak van historische CVE's zoals CVE-2015-9235); (3) HMAC secrets moeten random zijn en minstens 32 bytes, nooit korte strings; (4) verificatie is meer dan alleen handtekening checks — je moet ook `exp` (vervaltijd), `nbf` (not-before), `iss` (issuer) en `aud` (audience) valideren. Deze tool markeert elk van deze Claims in de UI zodat je in één oogopslag kunt zien of een failure een handtekening probleem, een timing probleem, of een Claims probleem is.
JWT is geen vervanging voor sessies. Sessies slaan gebruikersstatus op de server op (Redis of een database); JWT stopt de status in het token. Microservice architecturen, stateless APIs, mobiele clients en CORS-heavy setups profiteren van JWT; traditionele enterprise systemen en flows die directe intrekking vereisen (bijv. 'kick deze gebruiker er nu uit') zijn nog steeds beter bediend met sessies. Deze tool dekt zowel pure JWT debugging als de Token-parsing / signature-verifying / Payload-editing stappen van een sessie-naar-JWT migratie.