Geen upload, 100% lokaal, geen account

Stappenplan

Een JWT decoderen zonder te lekken

Een JSON Web Token draagt echte gegevens: aan welke gebruiker hij is uitgegeven, welke scopes hij toekent, wanneer hij verloopt. Hem in een willekeurige online decoder plakken betekent dat je die gegevens, en vaak een nog geldige sessie, overhandigt aan een server die je niet beheert. De decoder hieronder draait volledig in je browser, zodat je kunt lezen wat er in een token zit, kunt controleren of hij verlopen is en een HMAC-handtekening kunt bevestigen wanneer je de sleutel kent, allemaal zonder dat er ook maar één netwerkverzoek je tabblad verlaat.

Geschreven door Bastien Sulyan · Gepubliceerd op

Stap voor stap

  1. Open de JWT-decoder en plak je token in het invoerveld. Een JWT bestaat uit drie Base64Url-delen die met punten zijn samengevoegd: header, payload en handtekening. Je kunt hem met het Bearer-voorvoegsel of zonder plakken; de tool leest de structuur in beide gevallen en meldt meteen of het formaat verkeerd is.
  2. Lees de gedecodeerde header en payload. De header toont het ondertekeningsalgoritme (bijvoorbeeld HS256 of RS256) en de sleutel-id indien aanwezig. De payload somt de claims op: voor wie de token bestemd is (sub), wie hem heeft uitgegeven (iss) en de tijdstempels. De tool zet de numerieke velden iat, nbf en exp om in leesbare datums en geeft aan of de token nog geldig is of al verlopen.
    Een gedecodeerde JWT die het header-algoritme toont en de payload-claims met leesbare uitgifte- en vervaldatums
  3. Gebruikt de token HS256 en heb je het gedeelde geheim, plak dat geheim dan in het verifieerveld en klik op Verifieer. De tool berekent de HMAC over de header en payload opnieuw en vergelijkt die met de handtekening, zodat je weet of de token echt is of is gemanipuleerd. Bij RS256- of ES256-tokens vindt de ondertekening plaats met een privésleutel die jij niet hebt, dus de tool inspecteert de claims maar beweert niet de handtekening te verifiëren.
    Het HMAC-verifieerveld ingevuld met het gedeelde geheim en een badge voor geldige handtekening voor een HS256-token

Waarom je een token nooit op een willekeurige site moet plakken

Een JWT is niet versleuteld. De header en payload zijn alleen Base64Url-gecodeerd, wat betekent dat iedereen die de token ontvangt elke claim erin kan lezen: e-mail, gebruikers-id, rollen, interne markeringen. Is de token een toegangstoken dat nog niet is verlopen, dan kan wie hem in handen heeft hem opnieuw afspelen en in jouw naam handelen totdat hij verloopt. Wanneer je een actieve token in een gehoste decoder plakt, stuur je dat allemaal naar de logs van die server. De token op je eigen machine decoderen, zonder upload, is de enige manier om hem te inspecteren zonder de kring van mensen die hem kunnen zien te vergroten. Je kunt bevestigen dat er nul verkeer is door het netwerkpaneel te openen terwijl je decodeert.

Wat de handtekening je wel en niet kan vertellen

De handtekening is wat voorkomt dat iemand de claims bewerkt en ermee wegkomt. Bij een HS256-token ondertekent en verifieert hetzelfde geheim, dus als je het geheim kent kun je hier volledig bevestigen dat de token authentiek is. Bij RS256- en ES256-tokens ondertekent een privésleutel de token en verifieert alleen de bijbehorende publieke sleutel die; de privésleutel verlaat de uitgever nooit, dus een tool aan de clientzijde kan de claims lezen maar kan zonder die publieke sleutel de handtekening niet eerlijk bewijzen. Behandel de gedecodeerde payload als een bewering van de uitgever, niet als bewijs, totdat de handtekening is gecontroleerd door wie de verifieersleutel bezit. Om geheimen apart te hashen of te vergelijken, draait ook de hashgenerator op deze site lokaal.

JWT-structuur en wat elk onderdeel onthult

Een JWT bestaat uit drie Base64url-gecodeerde segmenten gescheiden door punten: header, payload en handtekening. De header verklaart het tokentype ("JWT") en het algoritme: HS256 (HMAC-SHA-256, een gedeeld geheim) of RS256 (RSA-SHA-256, een publiek/privé sleutelpaar) zijn de meest voorkomende. De payload bevat claims zoals `sub` (subject, gewoonlijk een gebruikers-ID), `iat` (uitgegeven-op Unix-tijdstempel), `exp` (vervaldatum Unix-tijdstempel), `aud` (beoogd publiek) en aangepaste toepassingsclaims zoals rollen of scopes. Base64url is geen versleuteling: het is een URL-veilige variant van Base64 die `+` vervangt door `-` en `/` door `_`, en opvulling weglaat. Iedereen die de ruwe tokenreeks heeft, kan de header en payload decoderen zonder de ondertekeningssleutel. Alleen het handtekeningsegment vereist de sleutel om te verifiëren. Dit is waarom het plakken van een live productietoken in een externe online decoder een beveiligingsrisico is: als de `exp` van het token nog in de toekomst ligt en de service de invoer registreert, kan de sessie die het vertegenwoordigt worden gecompromitteerd.

De tools die in deze gids worden gebruikt

Veelgestelde vragen

Wordt mijn token naar een server gestuurd wanneer ik hem decodeer?

Nee. De decoder splitst de token, decodeert de header en payload met Base64Url en geeft ze in het geheugen weer. De optionele HMAC-controle gebruikt de ingebouwde Web Crypto API van je browser. Er gaat niets over het netwerk, en dat is belangrijk omdat een JWT vaak persoonsgegevens en een nog actieve sessie bevat. Open het netwerkpaneel van je browser terwijl je decodeert en je ziet geen enkel verzoek uitgaan.

Kan deze tool een RS256- of ES256-handtekening verifiëren?

Niet volledig, en hij zal niet doen alsof. HS256 gebruikt één gedeeld geheim voor zowel ondertekenen als verifiëren, dus door dat geheim te plakken kan de tool de handtekening in je browser bevestigen. RS256 en ES256 gebruiken een privésleutel om te ondertekenen en een aparte publieke sleutel om te verifiëren; de tool leest en valideert de claims en de vervaldatum maar gaat niet zover een handtekening te bevestigen die hij niet kan controleren. Verifieer die tokens bij de dienst die de publieke sleutel bezit.

Bronnen