JWT-decoder

Wat een JWT-decoder feitelijk doet

Een JSON Web Token (JWT) ziet eruit als een lange, ondoorgrondelijke string van willekeurige tekens, maar het is niet versleuteld en geen geheime cijfer. Het is een compacte, URL-veilige container die gestructureerde data tussen twee partijen transporteert. Plak een token in de decoder hierboven en hij splitst die string uit elkaar en toont je de echte JSON erin — de metadata, de claims, voor wie het token is, en wanneer het verloopt. Alles gebeurt direct in je browser. Het token wordt nooit geüpload, gelogd of ergens naartoe gestuurd, wat van groot belang is wanneer het ding dat je inspecteert een actieve sessiegeloofsbewijs is.

Drie delen, twee punten

Elke goed gevormde JWT bestaat uit drie Base64url-gecodeerde strings verbonden door punten: header.payload.handtekening. Dat enkele puntteken is hoe parsers weten waar het ene gedeelte eindigt en het volgende begint, en dat is waarom een token met het verkeerde aantal punten wordt afgewezen voordat er iets anders wordt gelezen.

De header is een klein JSON-object dat het token zelf beschrijft. Het bevat vrijwel altijd typ (het type, doorgaans JWT) en alg — het ondertekeningsalgoritme, zoals HS256 (HMAC met SHA-256) of RS256 (RSA met SHA-256). De header vertelt een verificateur precies hoe de handtekening is aangemaakt.

De payload is het deel waar de meeste mensen om geven. Het is een ander JSON-object met de claims — uitspraken over de gebruiker en het token. De specificatie sorteert claims in geregistreerde (standaard, gereserveerde namen), publieke, en privé (aangepaste namen die je zelf bedenkt voor je eigen app). Het decoderen van de payload onthult wie er is ingelogd, welke rol ze hebben, en wanneer hun sessie verloopt.

De handtekening is het cryptografische zegel. Het wordt berekend over de gecodeerde header en payload met het algoritme uit de header plus een geheim of privésleutel. Omdat het beide andere secties dekt, maakt elke wijziging in de header of payload — zelfs één enkel teken — de handtekening ongeldig.

De claims die je het vaakst ziet

De geregistreerde claims zijn korte drielettternamen gedefinieerd door RFC 7519 zodat verschillende systemen kunnen samenwerken. Een handvol verschijnt vrijwel overal:

• iss — issuer: wie het token heeft aangemaakt (je authenticatieserver of identiteitsprovider).
• sub — subject: het onderwerp waarover het token gaat, doorgaans een stabiele gebruikers-ID.
• aud — audience: de ontvanger waarvoor het token bedoeld is. Een API moet tokens afwijzen waarvan het publiek niet zijzelf is.
• exp — expiration time: een Unix-tijdstempel waarna het token niet meer mag worden geaccepteerd.
• iat — issued at: de Unix-tijdstempel waarop het token is aangemaakt.

Je kunt ook nbf (not before) en jti (een unieke token-ID) tegenkomen. Tijdstempels zijn seconden sinds 1970 in UTC, en dat is waarom een decoder die ze weergeeft als voor mensen leesbare datums de mentale rekensom bespaart om te controleren of een token al verlopen is.

Decoderen is niet verifiëren — dit is het deel dat mensen bijt

Dit onderscheid is het belangrijkste om te begrijpen over JWT's. Decoderen betekent de inhoud lezen: het vereist geen sleutel en iedereen die het token heeft, kan het doen, omdat Base64url een codering is, geen versleuteling. Verifiëren betekent bewijzen dat het token authentiek en ongewijzigd is — de handtekening herberekenen met het juiste geheim of de juiste publieke sleutel en bevestigen dat ze overeenkomen.

Dit tool decodeert. Het toont je wat het token zegt, niet of het token betrouwbaar is. Een token kan vervalst, verlopen of opnieuw afgespeeld zijn en toch perfect uitziende JSON decoderen. Maak nooit een autorisatiebeslissing op basis van gedecodeerde claims alleen. In productie verifieer je de handtekening server-side, controleer je exp, en bevestig je dat iss en aud overeenkomen met wat je verwacht — met behulp van een beproefd bibliotheek, nooit handgeschreven stringvergelijking.

Een payload is geen kluis

Omdat de payload alleen Base64url-gecodeerd is, is hij leesbaar voor iedereen die het token onderschept. Behandel alles erin als openbaar. Zet geen wachtwoorden, volledige creditcardnummers, geheime sleutels of gevoelige persoonsgegevens in JWT-claims — als je het hier met één klik kunt decoderen, kan dat ook iedereen anders doen die een kopie krijgt. De handtekening beschermt tegen wijziging, nooit tegen lezen. Als je de inhoud van de payload echt wilt verbergen, is dat werk voor JWE (versleutelde tokens), een geheel andere specificatie.

Privacy en verwante tools

Een token inspecteren is een gevoelige handeling, dus deze decoder draait volledig aan de clientzijde — het parsen is gewone JavaScript in je tabblad en niets verlaat je machine. Een sessietoken in een server-ondersteund tool plakken betekent een actief geloofsbewijs overhandigen aan een derde partij, wat precies is wat je moet vermijden. Zie voor de codering die eraan ten grondslag ligt onze Base64-tool, en verken de rest van onze ontwikkelaarstools voor meer on-device hulpmiddelen.

Veelgestelde vragen