Decodeer en inspecteer JSON Web Tokens (JWT)

Een JSON Web Token (JWT) is een compacte en op zichzelf staande manier om informatie veilig tussen partijen uit te wisselen als een JSON-object. Op het eerste gezicht lijkt een JWT op een willekeurige reeks tekens, maar het heeft een duidelijke structuur die bestaat uit drie delen, gescheiden door punten (.):

header.payload.handtekening

1. Header: Het eerste deel identificeert welk algoritme is gebruikt om de handtekening te genereren. Meestal bevat het twee velden: alg (algoritme, bijv. HS256 of RS256) en typ (token type, wat bijna altijd JWT is). De header is een JSON-object dat vervolgens met Base64Url wordt gecodeerd.

1. Payload: Het tweede deel bevat de 'claims'. Dit zijn beweringen over een entiteit (meestal de gebruiker) en aanvullende gegevens. Er zijn geregistreerde claims (zoals iss voor uitgever, exp voor vervaltijd en sub voor onderwerp), publieke claims en private claims. Net als de header is de payload een JSON-object dat met Base64Url is gecodeerd. De Base64-decodering van dit deel onthult de informatie die het token transporteert.

1. Handtekening (Signature): Om de handtekening te creëren, worden de gecodeerde header, de gecodeerde payload, een geheim (secret) en het in de header gespecificeerde algoritme gebruikt. De handtekening wordt gebruikt om te verifiëren dat de afzender van de JWT is wie hij zegt te zijn en om te garanderen dat het bericht onderweg niet is gewijzigd.

Onze JWT Decoder neemt de volledige token-string, splitst deze in drie delen en decodeert de header en payload zodat u de inhoud kunt inspecteren. De inhoud wordt als een leesbaar JSON-object gepresenteerd, wat u verder kunt analyseren met een JSON Formatter.

De payload van een JWT bevat 'claims', wat stukjes informatie zijn over de gebruiker of het token zelf. Hoewel ontwikkelaars eigen, private claims kunnen definiëren, specificeert de RFC 7519-standaard een set van zeven geregistreerde claims die interoperabiliteit bevorderen. Dit zijn de meest voorkomende:

iss (Issuer): Identificeert de principal die het JWT heeft uitgegeven. Dit is vaak een URL van de authenticatieserver, zoals https://auth.voorbeeld.nl. sub (Subject): Identificeert het onderwerp van de JWT. Dit is meestal de unieke ID van de gebruiker, bijvoorbeeld 1234567890. aud (Audience): Identificeert de ontvangers waarvoor de JWT bedoeld is. De ontvanger moet zichzelf in deze claim herkennen, anders moet het token worden afgewezen. Dit kan een enkele string zijn of een array van strings, bijvoorbeeld https://api.voorbeeld.nl. exp (Expiration Time): Definieert de vervaltijd waarna de JWT niet meer geaccepteerd mag worden. Het is een numerieke waarde die de seconden sinds de Unix Epoch (1 januari 1970) representeert. Een JWT Decoder tool is essentieel om deze timestamp snel om te zetten naar een leesbare datum en tijd. nbf (Not Before): Identificeert de tijd vóór welke de JWT niet geaccepteerd mag worden. Net als exp is dit een Unix-timestamp. Dit is nuttig om tokens te creëren die pas in de toekomst geldig worden. iat (Issued At): Geeft aan op welk tijdstip de JWT is uitgegeven. Ook dit is een Unix-timestamp. Het kan worden gebruikt om de leeftijd van het token te bepalen.

Het correct interpreteren van deze claims is cruciaal voor het beveiligen van applicaties. Onze JWT Decoder toont niet alleen de ruwe timestamp-waarden, maar converteert exp, nbf en iat ook direct naar een voor mensen leesbaar datum- en tijdformaat.

In de context van JSON Web Tokens worden de termen 'decoderen' en 'verifiëren' vaak door elkaar gehaald, maar ze betekenen fundamenteel verschillende dingen. Het is cruciaal om het onderscheid te begrijpen voor de veiligheid van uw applicatie.

Decoderen is het proces van het omzetten van de Base64Url-gecodeerde header en payload van een JWT terug naar hun oorspronkelijke JSON-formaat. Iedereen die een JWT bezit, kan dit doen. Het vereist geen geheim of sleutel. Een JWT Decoder, zoals deze tool, leest simpelweg de openbare informatie in het token. Het is vergelijkbaar met het openen van een onverzegelde envelop om de brief erin te lezen. De inhoud is zichtbaar, maar de authenticiteit is niet gegarandeerd.

Verifiëren is het proces waarbij wordt gecontroleerd of de handtekening (het derde deel van de JWT) geldig is. Dit proces bevestigt twee dingen: 1. Authenticiteit: Het token is daadwerkelijk ondertekend door de partij die de geheime sleutel (voor symmetrische algoritmes zoals HS256) of de private sleutel (voor asymmetrische algoritmes zoals RS256) bezit. 2. Integriteit: De header en de payload zijn niet gewijzigd sinds het token werd ondertekend.

Onze JWT Decoder voert geen verificatie uit. Het toont u alleen de inhoud van de header en de payload. Behandel de gedecodeerde informatie daarom nooit als vertrouwd zonder de handtekening te verifiëren in uw backend-code met de juiste sleutel. Het decoderen van een token is een nuttige stap voor debugging, maar het is slechts de helft van het verhaal als het op beveiliging aankomt.

Wanneer een API-verzoek met een 401 Unauthorized of 403 Forbidden fout retourneert, is een ongeldig of onjuist geconfigureerd JWT vaak de oorzaak. Een JWT Decoder is een onmisbaar hulpmiddel voor ontwikkelaars om deze problemen snel te diagnosticeren. Door het token in de tool te plakken, kunt u direct de meest voorkomende problemen identificeren.

* Verlopen Token: Het meest voorkomende probleem. Zoek in de gedecodeerde payload naar de exp (Expiration Time) claim. De tool zal de Unix-timestamp vertalen naar een leesbare datum. Als die datum in het verleden ligt, is het token verlopen en moet de client een nieuw token aanvragen.

* Verkeerde Audience: De aud (Audience) claim specificeert voor welke API of service het token bedoeld is. Als de waarde van de aud claim niet overeenkomt met de identifier van uw API, zal de server het token terecht weigeren. Controleer of de client het token voor de juiste audience aanvraagt.

* Token nog niet geldig: De nbf (Not Before) claim geeft aan vanaf welk moment het token gebruikt mag worden. Als een API-verzoek wordt gedaan vóór deze tijd, is het token ongeldig. Dit kan gebeuren door configuratiefouten of klokverschillen.

* Klokverschil (Clock Skew): Kleine verschillen tussen de klok van de server die het token uitgeeft en de server die het valideert, kunnen problemen veroorzaken met de exp, nbf en iat claims. Als een token bijvoorbeeld wordt uitgegeven met een iat (Issued At) die volgens de validerende server in de toekomst ligt, kan het worden afgewezen. Door de timestamps te inspecteren, kunt u nagaan of een significant klokverschil de oorzaak is.

Met een JWT Decoder kunt u deze claims in enkele seconden controleren, wat u uren aan giswerk en logboekanalyse kan besparen.

Is het decoderen van een JWT hetzelfde als het verifiëren ervan? Nee, absoluut niet. Decoderen is het leesbaar maken van de informatie in de header en payload, die met Base64Url zijn gecodeerd. Iedereen kan dit doen. Verifiëren is het controleren van de digitale handtekening met een geheim (secret) om te bewijzen dat het token authentiek is en niet is gemanipuleerd. Onze tool decodeert alleen; het verifieert niet. Vertrouw nooit op de inhoud van een token zonder de handtekening te verifiëren.

Hoe controleer ik wanneer mijn token verloopt? Plak uw JWT in de decoder. In de gedecodeerde payload ziet u een claim genaamd exp. Dit is een Unix-timestamp die aangeeft wanneer het token verloopt. Onze tool converteert deze numerieke waarde automatisch naar een voor mensen leesbare datum en tijd, zodat u direct kunt zien of het token nog geldig is.

Is het veilig om hier een productietoken te plakken? Ja, het is veilig. Deze JWT Decoder werkt volledig lokaal in uw webbrowser. De data die u in het invoerveld plakt, wordt nooit naar onze servers of enige andere externe partij verzonden. Alle verwerking gebeurt aan de client-zijde (client-side). U kunt uw netwerkverkeer controleren om dit te bevestigen. Dit waarborgt de vertrouwelijkheid van uw tokens, zelfs die van productieomgevingen.

Waarom kan mijn token niet gedecodeerd worden? Als de decoder een fout geeft, zijn er een paar veelvoorkomende oorzaken. Ten eerste, controleer of de string wel een valide JWT is: het moet uit drie delen bestaan, gescheiden door twee punten (.). Ten tweede, elk van deze delen (met name de header en payload) moet een geldige Base64Url-gecodeerde string zijn. Als de codering corrupt is, bijvoorbeeld door verkeerd kopiëren en plakken, zal de decodering mislukken. U kunt proberen de afzonderlijke delen te decoderen met een Base64 decoder om het probleem te isoleren.