Wat is JWT?

JWT, uitgesproken als “jot” en voluit JSON Web Token, is een open standaard (RFC 7519) voor het veilig overdragen van informatie tussen systemen in de vorm van een compact, zelfbeschrijvend token. JWT wordt het meest gebruikt voor authenticatie en autorisatie: wanneer een gebruiker inlogt op een applicatie, ontvangt die een JWT die bij elk volgend verzoek wordt meegestuurd, zodat de server weet wie de aanvrager is en welke rechten die heeft. Denk aan een mobiele app die communiceert met een backend-API: de app logt in met gebruikersnaam en wachtwoord, ontvangt een JWT, en gebruikt dat token vervolgens bij elke API-aanroep zonder dat de gebruiker telkens opnieuw hoeft in te loggen. Bij microservices-architecturen maakt JWT het mogelijk dat één authenticatieservice tokens uitgeeft die door tientallen andere services worden geaccepteerd zonder dat ze allemaal de database hoeven te raadplegen. JWT is daarmee een van de meest gebruikte standaarden in moderne webontwikkeling en API-beveiliging.

De structuur van een JWT

Een JWT bestaat uit drie delen, gescheiden door punten: header.payload.signature. Elk deel is afzonderlijk Base64url-gecodeerd, waardoor het token URL-veilig is en in een HTTP-header kan worden meegestuurd.

Header

De header bevat metadata over het token zelf: het type token (JWT) en het gebruikte hashing-algoritme voor de handtekening. Een veelgebruikt algoritme is HS256 (HMAC met SHA-256) voor symmetrische handtekeningen, of RS256 (RSA met SHA-256) voor asymmetrische handtekeningen waarbij een private key tekent en een public key verifieert.

Payload

De payload bevat de claims: stukjes informatie over de gebruiker of het verzoek. Er zijn drie soorten claims:

• Registered claims: gestandaardiseerde claims zoals iss (issuer: wie het token heeft uitgegeven), sub (subject: over wie het token gaat), exp (expiration: wanneer het token verloopt) en iat (issued at: wanneer het token is aangemaakt).
• Public claims: zelfgedefinieerde claims die breed geaccepteerd worden, zoals een gebruikersrol of e-mailadres.
• Private claims: organisatiespecifieke claims die alleen binnen jouw systemen relevant zijn.

Belangrijk: de payload is alleen Base64url-gecodeerd, niet versleuteld. Iedereen die het token heeft, kan de payload lezen. Sla daarom nooit gevoelige informatie zoals wachtwoorden of creditcardgegevens op in een JWT-payload.

Signature

De handtekening is het beveiligingselement van JWT. Ze wordt berekend door de gecodeerde header en payload samen te nemen en te hashen met een geheime sleutel of private key. De ontvangende partij kan de handtekening verifiëren om te bevestigen dat het token niet is gemanipuleerd en afkomstig is van een vertrouwde bron. Als iemand de payload aanpast — bijvoorbeeld om zijn eigen rol te wijzigen van “gebruiker” naar “beheerder” — klopt de handtekening niet meer en wordt het token afgewezen.

JWT in authenticatieflows

De meest voorkomende toepassing van JWT is de Bearer token authenticatie. De flow werkt als volgt:

1. De gebruiker stuurt zijn inloggegevens (gebruikersnaam + wachtwoord) naar de authenticatieserver.
2. De server verifieert de gegevens en genereert een JWT met de relevante claims (gebruikers-ID, rollen, vervaldatum).
3. De server stuurt het JWT terug naar de client.
4. De client slaat het JWT op (bij voorkeur in geheugen of een httpOnly-cookie) en stuurt het mee bij elk API-verzoek via de Authorization: Bearer [token] HTTP-header.
5. De API-server valideert de handtekening, controleert de vervaldatum en leest de claims uit de payload om het verzoek te autoriseren.

Het grote voordeel van deze aanpak is dat de server geen sessie-informatie in een database hoeft op te slaan: alle benodigde informatie zit in het token zelf. Dit maakt JWT bijzonder geschikt voor stateless API’s en gedistribueerde systemen.

JWT versus sessiebeheer: wanneer gebruik je wat?

JWT is niet altijd de beste keuze. Vergelijk het met traditioneel sessiebeheer via server-side sessies:

• Sessiebeheer: de server slaat sessie-informatie op in een database of geheugen. De client ontvangt alleen een sessie-ID. Voordeel: tokens kunnen direct worden ingetrokken door de sessie te verwijderen. Nadeel: vereist gedeelde sessieopslag bij meerdere servers, wat complexer is.
• JWT: alle informatie zit in het token. Voordeel: stateless, schaalt eenvoudig horizontaal. Nadeel: een JWT kan niet worden ingetrokken voordat hij verloopt, tenzij je een token-blacklist bijhoudt — wat de stateloosheid deels ondermijnt.

JWT is bij uitstek geschikt voor API’s die worden aangesproken door mobiele apps of single-page applications, microservices-authenticatie en situaties waarbij horizontale schaalbaarheid belangrijk is. Traditioneel sessiebeheer past beter bij traditionele server-rendered webapplicaties of situaties waarbij directe intrekking van toegang cruciaal is.

Beveiliging: veelgemaakte fouten met JWT

JWT wordt regelmatig verkeerd geïmplementeerd, met ernstige beveiligingsproblemen als gevolg. De meest voorkomende fouten zijn:

• Algoritme “none” accepteren: sommige libraries accepteren tokens met het algoritme “none”, wat betekent dat er geen handtekening wordt gevalideerd. Zorg ervoor dat jouw library dit expliciet verbiedt.
• Zwakke geheime sleutels: gebruik voor HS256 een willekeurige sleutel van minimaal 256 bits. Een korte of voorspelbare sleutel maakt brute-force aanvallen mogelijk.
• Tokens opslaan in localStorage: localStorage is toegankelijk voor JavaScript, wat het kwetsbaar maakt voor XSS-aanvallen. Gebruik bij voorkeur httpOnly-cookies voor het opslaan van tokens in browserapplicaties.
• Geen vervaldatum instellen: een JWT zonder exp-claim is eeuwig geldig. Stel altijd een korte vervaldatum in (15 minuten tot enkele uren) en gebruik refresh tokens voor langere sessies.
• Gevoelige data in de payload: de payload is leesbaar voor iedereen die het token heeft. Sla nooit wachtwoorden, betalingsgegevens of andere vertrouwelijke informatie op in claims.

Conclusie

JWT is een krachtige en breed ondersteunde standaard voor authenticatie en informatie-overdracht in moderne webapplicaties en API’s. De stateloze aard maakt het bijzonder geschikt voor gedistribueerde systemen en microservices, terwijl de compacte formaat en brede bibliotheekundersteuning de implementatie eenvoudig houden. Tegelijkertijd vraagt JWT om zorgvuldige implementatie: verkeerd gebruik leidt tot ernstige beveiligingslekken die aanvallers kunnen exploiteren. Zorg dat je de structuur begrijpt, sterke sleutels gebruikt, tokens kort laat leven en veilig opslaat. Met de juiste kennis en zorgvuldige implementatie is JWT een betrouwbaar fundament voor jouw authenticatiestrategie. Wil je ermee beginnen? Verken de officiële documentatie op jwt.io, waar je ook tokens kunt decoderen en debuggen.

Veelgestelde vragen

1. Is JWT hetzelfde als OAuth?
   Nee, JWT en OAuth zijn verschillende concepten die vaak samen worden gebruikt. OAuth is een autorisatieprotocol dat beschrijft hoe een applicatie toegang krijgt tot resources namens een gebruiker. JWT is een tokenformaat dat vaak wordt gebruikt als het toegangstoken binnen een OAuth-flow. Je kunt OAuth implementeren zonder JWT, en JWT gebruiken buiten een OAuth-context.
2. Hoe trek ik een JWT in voordat hij verloopt?
   Dat is de grootste beperking van JWT: een geldig token kan niet worden ingetrokken zonder extra mechanismen. De meest gebruikte oplossing is een token-blacklist: een database of cache (zoals Redis) waarin ingetrokken tokens worden opgeslagen en bij elk verzoek worden gecontroleerd. Dit introduceert wel een server-side state, wat de stateloosheid van JWT deels ondermijnt. Korte vervaldatums (15–60 minuten) beperken het risico van gecompromitteerde tokens.
3. Wat is het verschil tussen een access token en een refresh token?
   Een access token is een kortlevend JWT (minuten tot uren) dat bij elk API-verzoek wordt meegestuurd. Een refresh token is een langlevend token (dagen tot weken) dat uitsluitend wordt gebruikt om een nieuw access token op te vragen wanneer het huidige verloopt. Deze scheiding beperkt het risico: een gelekt access token is snel waardeloos, terwijl de refresh token veilig kan worden opgeslagen en geroteerd.
4. Kan ik de JWT-payload versleutelen?
   Ja, daarvoor bestaat de JWE-standaard (JSON Web Encryption), een uitbreiding op JWT die de payload daadwerkelijk versleutelt zodat alleen de beoogde ontvanger die kan lezen. JWE is echter complexer te implementeren dan standaard JWT en wordt minder breed ondersteund. Voor de meeste toepassingen is het voldoende om geen gevoelige data in de payload op te slaan, in plaats van volledige versleuteling te gebruiken.
5. Welke programmeertalen ondersteunen JWT?
   Vrijwel alle moderne programmeertalen hebben volwassen JWT-libraries beschikbaar. Voor JavaScript/Node.js is jsonwebtoken de meest gebruikte library. Python heeft PyJWT, Java heeft JJWT en Nimbus JOSE+JWT, PHP heeft firebase/php-jwt, en Go heeft golang-jwt/jwt. Op jwt.io vind je een uitgebreide lijst van gevalideerde libraries per taal.