JWT Encoder: JSON Web Tokens aanmaken en ondertekenen voor authenticatie

Wat is een JWT?

Een JSON Web Token (JWT) is een compact, URL-veilig tokenformaat dat wordt gebruikt voor het veilig verzenden van informatie tussen partijen als een JSON-object. Een JWT bestaat uit drie Base64URL-gecodeerde delen gescheiden door punten: header.payload.handtekening. De header specificeert het ondertekeningsalgoritme, de payload bevat de claims (gegevens), en de handtekening verifieert dat het token niet is gemanipuleerd.

JWT's maken stateless authenticatie mogelijk — de server hoeft geen sessiegegevens op te slaan omdat alle benodigde informatie in het token zelf is ingebed. Dit maakt JWT's ideaal voor gedistribueerde systemen, microservices en API's waar sessieopslag complexiteit en latentie zou toevoegen.

JWT-structuur uitgelegd

Elke JWT bestaat uit drie afzonderlijke delen, elk met een specifieke rol in de levenscyclus van het token:

• Header — een JSON-object dat het tokentype (typ: JWT) en het ondertekeningsalgoritme (alg: HS256, RS256, enz.) specificeert, vervolgens Base64URL-gecodeerd
• Payload — een JSON-object met claims zoals iss (uitgever), sub (onderwerp), exp (vervaltijd), iat (uitgiftedatum), en eventuele aangepaste gegevens die u wilt verzenden
• Handtekening — gemaakt door de gecodeerde header en payload te ondertekenen met een geheime sleutel (HMAC) of privesleutel (RSA/ECDSA), waardoor de integriteit van het token wordt gewaarborgd

De payload is niet versleuteld — iedereen kan deze decoderen en lezen. Sla nooit gevoelige informatie zoals wachtwoorden of creditcardnummers op in een JWT-payload. De handtekening garandeert alleen dat de gegevens niet zijn gewijzigd, niet dat ze verborgen zijn.

Ondertekeningsalgoritmen

De keuze van het ondertekeningsalgoritme bepaalt hoe de JWT-handtekening wordt aangemaakt en geverifieerd. Er zijn drie hoofdfamilies van algoritmen:

• HMAC (HS256, HS384, HS512) — symmetrische algoritmen die dezelfde geheime sleutel gebruiken voor zowel ondertekening als verificatie. Eenvoudig te implementeren, het beste voor setups met een enkele server waar de uitgever en verificator hetzelfde geheim delen
• RSA (RS256, RS384, RS512) — asymmetrische algoritmen die een privesleutel gebruiken om te ondertekenen en een publieke sleutel om te verifieren. Ideaal voor gedistribueerde systemen waar meerdere services tokens moeten verifieren zonder toegang tot de ondertekeningssleutel
• ECDSA (ES256, ES384, ES512) — asymmetrische algoritmen die elliptische curve-cryptografie gebruiken. Bieden dezelfde beveiliging als RSA met aanzienlijk kleinere sleutelgroottes en snellere berekening, goed geschikt voor mobiele en IoT-toepassingen

Voor de meeste webapplicaties is HS256 voldoende wanneer zowel de tokenuitgever als de consument dezelfde server zijn. Kies RS256 of ES256 wanneer tokens door derden of tussen verschillende services moeten worden geverifieerd.

Coderen vs decoderen

Het coderen van een JWT betekent het aanmaken van een nieuw token door de header, payload samen te stellen en de handtekening te genereren met uw geheime of privesleutel. Dit gebeurt meestal aan de serverzijde tijdens het inloggen of het vernieuwen van het token. De resulterende tokenstring wordt naar de client gestuurd voor volgende geauthenticeerde verzoeken.

Het decoderen van een JWT kan twee dingen betekenen: het extraheren van de payload-claims zonder de handtekening te verifieren (nuttig voor het lezen van tokenmetadata aan de clientzijde), of het volledig verifieren van de handtekening om te bevestigen dat het token authentiek en ongewijzigd is. Productiesystemen moeten altijd de handtekening verifieren voordat ze claims in de payload vertrouwen.

Veelvoorkomende toepassingen

JWT's zijn de standaard geworden voor moderne authenticatie- en autorisatiepatronen in web- en mobiele applicaties:

• API-authenticatie — clients nemen het JWT op in de Authorization-header (Bearer token) bij elk verzoek, waardoor de server de identiteit kan verifieren zonder databaseraadplegingen
• OAuth 2.0 toegangstokens — OAuth-providers geven JWT's uit als toegangstokens die scope- en permissie-informatie bevatten voor geautoriseerde API-toegang
• Microservice-communicatie — services geven JWT's door om gebruikersidentiteit en permissies te propageren over servicegrenzen heen zonder gecentraliseerde sessieopslag
• Single Sign-On (SSO) — een centrale identiteitsprovider geeft een JWT uit die meerdere applicaties accepteren, waardoor gebruikers zich eenmaal kunnen authenticeren en toegang krijgen tot alle verbonden services

Beveiligingspraktijken

JWT's zijn krachtig maar vereisen zorgvuldige implementatie om veelvoorkomende beveiligingsvalkuilen te vermijden:

• Stel korte vervaltijden in — gebruik exp-claims van 15 minuten tot 1 uur voor toegangstokens, en implementeer rotatie van vernieuwingstokens voor langere sessies
• Sla nooit gevoelige gegevens op in de payload — JWT-payloads zijn alleen Base64URL-gecodeerd, niet versleuteld. Iedereen met het token kan de claims lezen
• Valideer altijd alle claims — verifieer exp, iss, aud en eventuele aangepaste claims bij elk verzoek. Vertrouw de payload niet zonder volledige handtekeningverificatie
• Gebruik uitsluitend HTTPS — verzend JWT's alleen via versleutelde verbindingen om tokenonderschepping via man-in-the-middle-aanvallen te voorkomen
• Weiger het "none"-algoritme — valideer altijd dat de alg-header overeenkomt met uw verwachte algoritme. Het "none"-algoritme omzeilt de handtekeningverificatie volledig

Veelgestelde vragen

Wat is het verschil tussen JWT en sessiecookies?

Sessiecookies slaan een sessie-ID op bij de client terwijl de werkelijke sessiegegevens op de server staan. JWT's zijn zelfstandig — alle gegevens zitten in het token zelf. Dit maakt JWT's stateless en gemakkelijker horizontaal schaalbaar, maar moeilijker om in te trekken omdat u niet simpelweg een sessie aan de serverzijde kunt verwijderen. Sessiecookies zijn eenvoudiger voor traditionele webapplicaties; JWT's zijn beter voor API's en gedistribueerde systemen.

Hoe trek ik een JWT in voordat het verloopt?

Aangezien JWT's stateless zijn, is er geen ingebouwd intrekkingsmechanisme. Veelvoorkomende strategieen zijn: het bijhouden van een tokenblokkeerlijst (controleren bij elk verzoek), het gebruik van kortlevende toegangstokens met rotatie van vernieuwingstokens (het intrekken van het vernieuwingstoken maakt toekomstige toegang ongeldig), of het opslaan van een tokenversie in het gebruikersrecord en deze verhogen bij uitloggen.

Is er een limiet voor de grootte van JWT's?

Er is geen formele groottelimiet in de JWT-specificatie, maar er bestaan praktische limieten. De meeste HTTP-servers beperken headergroottes tot 8 KB. Aangezien JWT's doorgaans in de Authorization-header worden verzonden, wordt aanbevolen tokens onder de 4 KB te houden. Grote payloads met veel claims kunnen deze limiet overschrijden — overweeg alleen essientiele claims in het JWT op te slaan en aanvullende gegevens via een API op te halen.