Wat is JWT? Betekenis en toepassing uitgelegd

Wat is JWT?

JWT (JSON Web Token) is een open standaard (RFC 7519) voor het veilig overdragen van informatie tussen partijen als een compact, URL-veilig JSON-object. JWT's worden breed ingezet voor stateless authenticatie en autorisatie in moderne webapplicaties en API's. Het token bevat zelf alle claims die nodig zijn om een verzoek te verifiëren, waardoor een centrale sessiestore overbodig wordt en horizontale schaalbaarheid eenvoudiger is.

Hoe werkt JWT technisch?

Een JWT bestaat uit drie delen, gescheiden door punten: header, payload en signature. De header bevat het tokentype (typ: "JWT") en het gebruikte ondertekeningsalgoritme (zoals HS256, RS256 of ES256). De payload bevat claims: geregistreerde claims (iss voor issuer, exp voor expiratie, sub voor subject, aud voor audience) en aangepaste claims die informatie over de gebruiker, rollen en rechten bevatten. De signature wordt berekend door de base64url-gecodeerde header en payload te combineren met een geheim (HMAC) of een privésleutel (RSA/ECDSA). Bij stateless authenticatie hoeft de server geen sessiedata op te slaan: alle benodigde informatie zit in het token zelf en wordt bij elk verzoek geverifieerd. Access tokens hebben een korte levensduur (doorgaans 5 tot 15 minuten) terwijl refresh tokens langer geldig zijn voor het verkrijgen van nieuwe access tokens. Refresh token rotation zorgt ervoor dat elk refresh token slechts eenmaal gebruikt kan worden, waardoor gestolen tokens sneller worden gedetecteerd. JWT's zijn ideaal voor microservice-architecturen omdat elke service het token onafhankelijk kan valideren met de publieke sleutel van de authenticatieservice, zonder een gedeelde database te raadplegen. JSON Web Key Sets (JWKS) publiceren publieke sleutels via een standaard endpoint, zodat services automatisch de juiste validatiesleutel ophalen en sleutelrotatie transparant verloopt. Belangrijke beveiligingsoverwegingen zijn: tokens altijd via HTTPS versturen, korte expiratie-tijden instellen, gevoelige data niet in de payload opnemen (base64 is geen encryptie), tokens veilig opslaan in httpOnly secure cookies in plaats van localStorage, audience en issuer claims valideren, en het "alg: none" probleem voorkomen door het ondertekeningsalgoritme server-side af te dwingen. JWE (JSON Web Encryption) versleutelt de gehele tokenpayload voor use cases waarbij de inhoud vertrouwelijk moet zijn, in tegenstelling tot JWS (JSON Web Signature) dat alleen integriteit garandeert. Token binding koppelt een JWT aan een specifiek TLS-certificaat van de client, waardoor gestolen tokens niet op andere apparaten bruikbaar zijn. Proof of Possession (DPoP) is een nieuwere RFC die een vergelijkbaar mechanisme biedt voor publieke clients. Bij het opschalen van microservice-architecturen wordt caching van JWKS-responses essentieel om de authenticatieservice niet te overbelasten, met een typische cache-TTL van 5 tot 60 minuten en een forced refresh bij onbekende key IDs. Token revocation blijft een uitdaging bij stateless tokens: veelgebruikte oplossingen zijn korte expiratie, een token blacklist in Redis of een combinatie met opaque reference tokens voor scenario's die onmiddellijke intrekking vereisen.

Hoe past MG Software JWT toe in de praktijk?

MG Software gebruikt JWT als standaard authenticatiemechanisme in onze API's en webapplicaties. We implementeren een access/refresh token-strategie met korte levensduur (10 minuten) voor access tokens en veilige httpOnly secure cookies voor refresh tokens met automatische rotation. In onze Supabase-integraties verwerken we JWT's voor Row Level Security: de database leest claims direct uit het token om autorisatie op rijniveau af te dwingen zonder extra API-calls. Voor microservice-architecturen gebruiken we JWT's ondertekend met RS256 of ES256 om verzoeken tussen services te authenticeren zonder een gedeelde sessiestore. We publiceren onze publieke sleutels via een JWKS-endpoint voor geautomatiseerde sleutelrotatie. Custom claims worden minimaal gehouden om de tokengrootte beheersbaar te houden en gevoelige data wordt nooit in de payload geplaatst. We implementeren token blacklisting via Redis voor scenario's waarin onmiddellijke invalidatie nodig is, zoals bij het resetten van wachtwoorden of het uitschakelen van accounts. Onze JWT-implementaties bevatten geautomatiseerde monitoring die waarschuwt bij ongebruikelijke patronen zoals een piek in verlopen tokens of tokens die van onbekende issuers afkomstig zijn.

Waarom is JWT belangrijk?

JWT maakt schaalbare authenticatie mogelijk in microservices en mobiele clients zonder centrale sessietabel per request. Als het ontwerp klopt, kunnen services onafhankelijk valideren en kunt u duidelijke expiratie, audience-controle en sleutelrotatie afdwingen voor toegang tot data. Voor organisaties die meerdere applicaties of API's aanbieden is JWT de standaard manier om identiteit en rechten over servicegrenzen heen te transporteren. De compacte, URL-veilige structuur maakt JWT geschikt voor HTTP-headers, query parameters en cross-domain communicatie. Een goed JWT-ontwerp vermindert de latency van authenticatie omdat validatie lokaal gebeurt met cryptografische verificatie in plaats van een roundtrip naar een sessieserver. Naarmate API-ecosystemen complexer worden met externe integraties en webhooks, biedt JWT een gestandaardiseerde manier om vertrouwen over organisatiegrenzen heen over te dragen.

Veelgemaakte fouten met JWT

Lange levensduur van access tokens combineren met opslag in localStorage, waar ze kwetsbaar zijn voor XSS-aanvallen. Gevoelige claims ondertekenen maar niet versleutelen terwijl clients de base64-gecodeerde payload gewoon kunnen lezen. Zwakke HMAC-secrets die in broncode staan en hetzelfde geheim voor alle omgevingen gebruiken. Het uitschakelen of niet valideren van exp-, aud- en iss-claims waardoor verlopen of verkeerd gerichte tokens worden geaccepteerd. Refresh tokens zonder rotation, waardoor een gestolen refresh token onbeperkt nieuwe access tokens kan ophalen. Tot slot het accepteren van het "alg: none" header-veld, waardoor aanvallers ongetekende tokens kunnen insturen die door een kwetsbare library als geldig worden beschouwd.

Welke voorbeelden zijn er van JWT?

• Een webapplicatie die na inloggen een JWT access token retourneert met een geldigheidsduur van 10 minuten, waarna een refresh token via een httpOnly cookie automatisch een nieuw access token aanvraagt zonder dat de gebruiker opnieuw hoeft in te loggen.
• Een microservice-architectuur waarbij elke service inkomende JWT-tokens valideert tegen de publieke sleutel van de authenticatieservice via een JWKS-endpoint, zonder een gedeelde database te raadplegen en met automatische sleutelrotatie.
• Een mobiele app die JWT-tokens opslaat in de secure storage van het besturingssysteem (iOS Keychain of Android Keystore) en bij elk API-verzoek meestuurt in de Authorization-header met Bearer-prefix.
• Een Supabase-backed applicatie waarbij de JWT custom claims bevat voor de gebruikersrol, zodat Row Level Security policies in PostgreSQL direct op basis van het token bepalen welke rijen een gebruiker mag lezen of wijzigen.
• Een single sign-on omgeving waarbij een identity provider JWT-tokens uitgeeft die door meerdere applicaties worden geaccepteerd, met audience-validatie die voorkomt dat een token voor app A wordt hergebruikt bij app B.

Gerelateerde begrippen