JWT-parser gids: JSON Web Tokens veilig decoderen, valideren en inspecteren

Je authenticatie is zojuist in productie stukgegaan. Gebruikers krijgen “Invalid Token”-fouten en je moet snel uitzoeken waarom. Je maakt de JWT open en het lijkt op onzin: drie blokken willekeurige tekens gescheiden door punten. De gegevens zitten erin, maar zonder een parser kun je ze niet lezen.

Een JWT-parser is een gespecialiseerde tool die de drie delen van een JSON Web Token — Header, Payload en Signature — opsplitst volgens de RFC 7519-standaard. Vanaf april 2026 decoderen deze parsers Base64URL-gecodeerde gegevens en verifiëren ze handtekeningen met secrets of public keys om ervoor te zorgen dat het token niet is gemanipuleerd, waarmee ze bedreigingen zoals de “alg: none”-aanval blokkeren.

Wat een JWT-parser echt doet

Beschouw een JWT-parser als een vertaler. Het neemt een lange, ondoorzichtige tekenreeks en zet deze terug om naar leesbare JSON-objecten. Dit is fundamenteel voor het beheren van gebruikersidentiteiten en het beveiligen van gegevensuitwisseling in moderne applicaties.

Intern zoekt de parser de twee punten (.) op die het token in drie secties verdelen:

Sectie	Doel	Gecodeerd?	Leesbaar zonder key?
Header	Metadata: ondertekeningsalgoritme (HS256, RS256)	Base64URL	Ja
Payload	Claims: gebruikersgegevens, vervaldatum, rollen	Base64URL	Ja
Signature	Digitale verzegeling die authenticiteit bewijst	HMAC/RSA	Nee — vereist key

Stapsgewijs decoderen: wat er vanbinnen gebeurt

Laten we een echt token doorlopen. Neem deze voorbeeld-JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4iLCJpYXQiOjE3MDAwMDAwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Stap 1: Splitsen op punten

[0] eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
[1] eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4iLCJpYXQiOjE3MDAwMDAwMDB9
[2] SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Stap 2: Base64URL-decode sectie [0] (Header)

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

Stap 3: Base64URL-decode sectie [1] (Payload)

{
  "sub": "1234567890",
  "name": "John",
  "iat": 1700000000
}

Stap 4: Verifieer sectie [2] (Signature) — vereist de secret key

De parser neemt de Base64URL-gecodeerde header + “.” + payload en berekent vervolgens een HMAC-SHA256 met de secret. Als het resultaat overeenkomt met sectie [2], is het token authentiek.

Belangrijke beveiligingsopmerking: Base64URL is geen versleuteling

Een veelvoorkomende valkuil voor nieuwe ontwikkelaars is de aanname dat de gecodeerde header en payload zijn versleuteld. Dat zijn ze niet. Zoals JustUse.me aangeeft, maakt Base64URL-codering JSON gewoon veilig om via URL’s en headers te verzenden. Iedereen die het token heeft, kan de payload decoderen zonder wachtwoord of key.

Bewaar nooit gevoelige gegevens (wachtwoorden, BSN’s, API-sleutels) in een JWT-payload. Ze zijn zichtbaar voor iedereen die het token onderschept.

Handtekeningverificatie: de beveiligingspoort

Hoewel iedereen de gegevens van een token kan lezen, is handtekeningverificatie wat je systeem daadwerkelijk veilig houdt. Een JWT-parser leest niet alleen informatie — hij bewijst waar deze vandaan komt.

De parser berekent de handtekening opnieuw met behulp van de header, payload en een key, en controleert vervolgens of het resultaat overeenkomt met de handtekening op het token. Als ze niet overeenkomen, is het token gemanipuleerd.

Twee algoritmefamilies

Algoritme	Key-type	Hoe het werkt	Veelvoorkomend gebruik
HS256 (HMAC)	Symmetrisch — dezelfde secret key voor ondertekenen en verifiëren	Beide partijen delen één secret	Authenticatie voor één service, microservices binnen één team
RS256 (RSA)	Asymmetrisch — private key ondertekent, public key verifieert	Afzender houdt private key; iedereen met public key kan verifiëren	OAuth2-providers, third-party API-integraties
ES256 (ECDSA)	Asymmetrisch —zelfde model als RSA maar met elliptische krommen	Kleinere keys, snellere verificatie	Mobiele apps, prestatiegevoelige services

De “alg: none”-aanval

Dit is een van de gevaarlijkste JWT-kwetsbaarheden. Een aanvaller past de header aan om "alg": "none" te claimen en verwijdert de handtekening. Een slecht geïmplementeerde parser zou dit kunnen accepteren en het token als geldig behandelen zonder enige verificatie.

Verdediging: Je parser moet elk token waarvan het algoritme “none” is of niet overeenkomt met je verwachte algoritme expliciet afwijzen. Stas Persiianenko, die de Apify JWT-tool ontwikkelde, benadrukt dat hoewel tokens transparant zijn qua ontwerp, hun beveiliging afhangt van de parser die niet-ondertekende of gemanipuleerde tokens strikt afwijst.

decoded = jwt.decode(token, key, algorithms=None)  # NEVER do this

decoded = jwt.decode(token, key, algorithms=["HS256"])

Standaard JWT-claims: wat elk veld betekent

Een JWT-parser haalt “claims” uit de payload. Deze volgen het JOSE (JSON Object Signing and Encryption)-raamwerk voor compatibiliteit tussen systemen.

Claim	Volledige naam	Doel	Voorbeeldwaarde
iss	Issuer	Wie het token heeft uitgegeven	"auth.example.com"
sub	Subject	De gebruiker of entiteit die het token vertegenwoordigt	"user:12345"
aud	Audience	Bedoelde ontvanger van het token	"api.example.com"
exp	Expiration Time	Wanneer het token ongeldig wordt	1700000000 (Unix-timestamp)
iat	Issued At	Wanneer het token is aangemaakt	1699999999
nbf	Not Before	Token is niet geldig vóór dit tijdstip	1699999999
jti	JWT ID	Unieke identificatie voor het token	"a1b2c3d4"

Bij gebruik van asymmetrische handtekeningen verwijzen parsers vaak naar een JWK (JSON Web Key) — een JSON-structuur die een public key vertegenwoordigt. De parser haalt automatisch de juiste JWK op van de metadata-endpoint van de uitgever om het token te verifiëren.

Implementatie: echte code voor productie

PHP met lcobucci/jwt

De standaard in het PHP-ecosysteem is lcobucci/jwt. Gegevens van Packagist tonen meer dan 322 miljoen installaties vanaf april 2026, wat het de standaardkeuze maakt voor Laravel- en Symfony-projecten.

use Lcobucci\JWT\Configuration;
use Lcobucci\JWT\Signer\Hmac\Sha256;
use Lcobucci\JWT\Signer\Key\InMemory;

$config = Configuration::forSymmetricSigner(
    new Sha256(),
    InMemory::plainText('your-secret-key')
);

// Parsing and validating a token
$token = $config->parser()->parse($jwtString);

// Verify constraints: expiration, issuer, etc.
$constraints = [
    new \Lcobucci\JWT\Validation\Constraint\IssuedBy('auth.example.com'),
    new \Lcobucci\JWT\Validation\Constraint\PermittedFor('api.example.com'),
    new \Lcobucci\JWT\Validation\Constraint\SignedWith(
        $config->signer(),
        $config->signingKey()
    ),
];

$isValid = $config->validator()->validate($token, ...$constraints);

Hono (Edge/Serverless) met Web Crypto

Voor lichtgewicht edge-applicaties biedt de Hono JWT Helper een minimale decode()-functie, perfect voor serverless platforms waar je snelle cold starts en minimale afhankelijkheden wilt.

import { jwt } from 'hono/jwt'

// Middleware to verify JWT on every request
app.use('/api/*', jwt({ secret: 'your-secret' }))

// Access decoded claims in your handler
app.get('/api/profile', (c) => {
  const payload = c.get('jwtPayload')
  return c.json({ user: payload.sub })
})

AI-gedreven JWT-analyse met MCP

Tegen 2026 stelt het Model Context Protocol (MCP) AI-assistenten zoals Claude Code of Cursor in staat rechtstreeks met JWT-tools te communiceren. Stel een MCP-server in en een ontwikkelaar kan een AI vragen om “Controleer alle JWT’s in deze logs op verval-fouten” — de agent handelt het parsen af via de command line.

Volgens Apify kost bulkverwerking ongeveer $11.50 per 10.000 tokens vanaf 2026. Deze automatisering stelt AI-agents in staat verlopen tokens te vinden en direct suggesties te doen voor codefixes voor de beveiligingsinstellingen van de app.

Conclusie

Een JWT-parser is meer dan een gemak bij het debuggen — het is een essentiële beveiligingscontrole. Het zorgt ervoor dat tokens authentiek zijn via handtekeningcontroles en geldig via claimverificatie. Onthoud de twee regels die het meest van belang zijn: Base64URL is geen versleuteling, dus bewaar nooit secrets in de payload. En specificeer altijd expliciet toegestane algoritmes om “alg: none”-aanvallen te voorkomen.

Gebruik voor productie-apps bewezen bibliotheken zoals lcobucci/jwt of de JWT-helper van Hono in plaats van je eigen parser te bouwen. Voor debugging en bulkanalyse zijn AI-gedreven MCP-tools de moderne aanpak om beveiligingsaudits geautomatiseerd en grondig te houden.

FAQ

Is het legaal om een JWT-token te decoderen dat ik in mijn browser heb gevonden?

Ja, het is volledig legaal. JWT’s zijn ontworpen om transparant te zijn — de header en payload zijn gecodeerd voor transport, niet versleuteld voor geheimhouding. Het bezitten van het token impliceert dat je toegang hebt tot de gegevens in de claims. Houd echter altijd rekening met lokale privacywetgeving zoals de AVG/GDPR wanneer tokens persoonlijke informatie bevatten.

Waarom toont mijn JWT-parser isExpired: true voor een token dat ik zojuist heb gegenereerd?

Dit wordt meestal veroorzaakt door klokafwijking (clock drift) tussen de server die het token genereerde en het systeem dat het parseert. Als de klokken van de twee systemen niet gesynchroniseerd zijn (via UTC/NTP), kunnen de exp– of nbf-claims ongeldig lijken. Los dit op door ervoor te zorgen dat beide systemen NTP gebruiken voor tijdsynchronisatie, of voeg een kleine “leeway” toe (meestal 60 seconds) in je parse-bibliotheek om kleine afwijkingen op te vangen.

Kan ik een JWT decoderen zonder de secret of public key te hebben?

Ja, je kunt altijd de Header en Payload decoderen en lezen zonder key, omdat ze simpelweg Base64URL-gecodeerde JSON zijn. Je kunt echter de Signature niet verifiëren of erop vertrouwen dat de gegevens authentiek zijn zonder de bijbehorende secret (voor HS256) of public key (voor RS256). Zonder verificatie moet je de gegevens beschouwen als ongeverifieerd en mogelijk gemanipuleerd.

Wat is de “alg: none”-aanval en hoe voorkom ik deze?

De “alg: none”-aanval maakt gebruik van parsers die het in de token-header gespecificeerde algoritme accepteren zonder validatie. Een aanvaller verandert de header in "alg": "none" en verwijdert de handtekening, waardoor een kwetsbare parser wordt misleid het token als geldig te accepteren. Voorkom dit door in je verificatiecode altijd expliciet toegestane algoritmes op te geven — accepteer nooit “none” en laat het token nooit bepalen welk algoritme wordt gebruikt.