Wat is een JWT? Inzicht in JSON-webtokens en staatloze authenticatie

Wanneer u inlogt op een moderne Single Page Application (zoals React of Vue) of een mobiele app, heeft de server een manier nodig om te onthouden wie u bent. Traditioneel deed het dit door een ‘sessie-ID’ op te slaan in een enorme database op de server, en een cookie in uw browser te plaatsen. Elke keer dat u op een knop klikte, moest de server dat ID opzoeken in zijn database. Dit wordt stateful authenticatie genoemd.

In het tijdperk van microservices en cloudschaling werden databases echter een knelpunt. Om dit op te lossen hebben ontwikkelaars Stateless Authentication via JSON Web Tokens (JWT) ingevoerd. Met JWT hoeft de server niet te onthouden wie u bent: uw browser vertelt de server precies wie u bent en gebruikt cryptografie om dit te bewijzen.

De anatomie van een JWT

Als u het netwerkverkeer inspecteert nadat u zich bij een moderne app heeft aangemeld, ziet u waarschijnlijk de kop 'Authorization: Bearer', gevolgd door een lange, willekeurig ogende reeks tekens, gescheiden door twee punten. Dat is een JWT.

Een JWT bestaat uit precies drie delen: Header.Payload.Signature.

1. De kop

Het eerste deel is een Base64URL-gecodeerd JSON-object dat eenvoudigweg het token beschrijft. Het bevat meestal twee eigenschappen: het type token (JWT) en het gebruikte ondertekeningsalgoritme (zoals HMAC SHA256 of RSA).

2. De lading (claims)

Het middelste gedeelte is ook een Base64URL-gecodeerd JSON-object. Dit is waar de feitelijke gegevens zich bevinden. Deze stukjes gegevens worden ‘claims’ genoemd. Het kan bijvoorbeeld uw gebruikers-ID, uw rol (bijvoorbeeld 'Beheerder') en een vervaltijdstempel bevatten. Omdat deze payload aan elk verzoek wordt gekoppeld, weet de server onmiddellijk wie u bent zonder een database te raadplegen.

KRITIEKE WAARSCHUWING: de payload is alleen gecodeerd, niet gecodeerd. Iedereen die een JWT onderschept, kan deze eenvoudig decoderen en de lading lezen. Bewaar nooit wachtwoorden, burgerservicenummers of gevoelige gegevens in een JWT-payload.

3. De handtekening

Als iedereen de payload kan lezen en bewerken, wat weerhoudt een kwaadwillende gebruiker er dan van zijn rol te veranderen van 'Gebruiker' in 'Beheerder'? Het antwoord is de handtekening.

Om de handtekening te maken, gebruikt de server de header, de payload en een zeer veilige geheime sleutel (alleen bekend bij de server) en voert deze door een cryptografisch algoritme (zoals SHA256). De resulterende hash wordt de handtekening.

Wanneer de server een token terugkrijgt van de client, herberekent hij de handtekening met behulp van zijn geheime sleutel. Als de gebruiker met de payload heeft geknoeid (zelfs door een enkele letter te wijzigen), komt de herberekende handtekening niet overeen met de handtekening op het token, en zal de server het verzoek onmiddellijk afwijzen als frauduleus.

Waarom microservices dol zijn op JWT's

Stel je een bedrijf als Netflix voor. Ze hebben een authenticatieserver, een videostreamingserver en een factureringsserver. Als ze traditionele sessies zouden gebruiken, zou elke afzonderlijke server voortdurend moeten communiceren met een centrale database om te controleren of een gebruiker is ingelogd.

Bij JWT's ondertekent de authenticatieserver het token met een privésleutel. De gebruiker geeft dat token vervolgens rechtstreeks door aan de videoserver. Omdat de videoserver over de publieke sleutel beschikt, kan deze de handtekening onafhankelijk verifiëren. De videoserver weet precies wie de gebruiker is, zonder ooit met de authenticatieserver of een database te praten. Hierdoor kan de infrastructuur oneindig worden geschaald zonder knelpunten.

De donkere kant: ongeldigverklaring van tokens

JWT's zijn niet perfect. Hun grootste kracht (staatloos zijn) is ook hun grootste zwakte. Omdat de server geen register bijhoudt van actieve tokens, kun je een gebruiker niet gemakkelijk uitloggen of een specifiek token ongeldig maken voordat het verloopt.

Als een hacker de JWT van een gebruiker steelt, heeft de hacker volledige toegang totdat het vervaltijdstempel van het token afloopt. Om dit risico te beperken, gebruiken beveiligingsingenieurs een systeem met twee tokens:

• Toegangstokens: JWT's met een korte levensduur (bijvoorbeeld 15 minuten) die worden gebruikt voor API-verzoeken.
• Tokens vernieuwen: stateful tokens met een lange levensduur, veilig opgeslagen, uitsluitend gebruikt om nieuwe toegangstokens aan te vragen. Als een account wordt gehackt, trekt de server het vernieuwingstoken in en verdwijnt het toegangstoken van de hacker uiteraard binnen 15 minuten.

Veelgestelde vragen (FAQ)