JWT uitgelegd: structuur, claims en hoe je er een decodeert

Als je met een moderne web-API hebt gewerkt, ben je JWT's tegengekomen — die lange brabbelstrings met twee punten die opduiken in login-antwoorden en Authorization-headers. Ze ogen ondoorzichtig, maar zijn verrassend leesbaar zodra je de structuur kent. Deze gids legt uit wat een JSON Web Token is, wat erin zit, hoe de handtekening werkt en welke beveiligingsfouten je moet vermijden.

Waar een JWT voor is

Een JSON Web Token (JWT) is een compacte, op zichzelf staande manier om een set claims te dragen — beweringen als „dit is gebruiker 42 en hij logde in om 10:05”. Het belangrijkste gebruik is authenticatie: na het inloggen geeft een server een JWT uit, je app stuurt het bij elk verzoek terug, en de server vertrouwt het in plaats van je elke keer op te zoeken in een sessieopslag. Omdat het token de informatie zelf draagt, heet het stateless.

De drie delen

Elk JWT bestaat uit drie met punten verbonden Base64URL-gecodeerde secties: header.payload.signature.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiJ9.3x9kQ...
└──── header ────┘ └── payload ──┘ └ signature ┘

1. Header

Metadata over het token — het handtekeningalgoritme (alg, bijv. HS256) en het type (typ: JWT). Gedecodeerd is het maar kleine JSON:

{ "alg": "HS256", "typ": "JWT" }

2. Payload

De claims — de eigenlijke data. Sommige namen zijn gestandaardiseerd (geregistreerde claims genoemd):

• sub — subject, meestal de gebruikers-ID.
• iss — uitgever (issuer), wie het token maakte.
• aud — doelgroep (audience), voor wie het bedoeld is.
• exp — verlooptijd (een Unix-tijdstempel).
• iat — uitgiftetijd (een Unix-tijdstempel).

Die exp- en iat-waarden zijn seconden sinds 1970 — moet je ze als echte datums lezen, dan zet een tijdstempel-omzetter ze om in leesbare tijden.

3. Handtekening (Signature)

De handtekening is wat het token betrouwbaar maakt. De uitgever neemt de header en payload en produceert met een geheime sleutel een cryptografische handtekening. Iedereen met de sleutel kan verifiëren dat header en payload niet zijn gewijzigd — verander één teken in de payload en de handtekening klopt niet meer.

Het belangrijkste om te begrijpen

Een JWT is ondertekend, niet versleuteld. De header en payload zijn slechts Base64URL-gecodeerd, wat betekent dat iedereen ze kan decoderen en lezen — geen sleutel nodig. De handtekening voorkomt manipulatie, niet lezen.

Het praktische gevolg: zet nooit geheimen in een JWT-payload. Geen wachtwoorden, geen creditcardnummers, geen privégegevens — ga ervan uit dat de payload openbaar is. Je kunt dit zelf bevestigen door een willekeurig token in onze JWT-decoder te plakken, die de header en claims direct leest, volledig in je browser (het token verlaat je apparaat nooit). Onder de motorkap is het gewoon Base64-decodering — de decoder bespaart je alleen de stappen.

Verifiëren vs. decoderen

Dit zijn twee verschillende handelingen, en ze verwarren is een echte beveiligingsfout. Decoderen leest de payload — iedereen kan het en het bewijst niets. Verifiëren controleert de handtekening met de sleutel en bevestigt dat het token echt en ongewijzigd is. Een server moet elk token verifiëren voordat hij het vertrouwt; decoderen alleen is geen authenticatie.

Veelvoorkomende valkuilen

• Een ongeverifieerd token vertrouwen — controleer de handtekening altijd server-side voordat je op de claims handelt.
• Verval negeren — respecteer exp; een verlopen token hoort te worden geweigerd.
• Gevoelige data in de payload opslaan — die is door iedereen leesbaar.
• De `alg: none`-valstrik — sommige bibliotheken accepteerden ooit tokens die „geen handtekening” claimden. Wijs ze af en leg het verwachte algoritme vast.

Begrijp dat, en JWT's gaan van intimiderende strings naar een simpel, transparant formaat: leesbare claims, beschermd door een handtekening die je moet verifiëren voordat je vertrouwt.