RevealTheme logo

JWT-decoder

Decodeer JSON Web Tokens (JWT) direct. Draait in uw browser: de tokens verlaten uw apparaat nooit, dus het is veilig te gebruiken met productiegeheimen.

Hoe u deze tool gebruikt

  1. 1

    Plak je JWT in het invoerveld.

  2. 2

    Klik op Decoderen. De header en payload worden geparsed en weergegeven.

  3. 3

    Inspecteer het algoritme, de claims, de vervaltijd en de uitgever.

Wat is een JWT en hoe werkt die?

Een JSON Web Token (JWT, gedefinieerd in RFC 7519) is een compacte, URL-veilige manier om een verzameling claims over een gebruiker weer te geven, met cryptografisch bewijs dat die claims niet zijn gemanipuleerd. JWT's vormen de basis van de authenticatie in de meeste moderne webstacks: wanneer u zich aanmeldt, maakt de server een JWT met uw gebruikers-ID en machtigingen, ondertekent die met een geheime sleutel en stuurt die naar u terug. Uw browser bewaart het token (meestal in localStorage of in een cookie) en voegt het toe aan de Authorization-header van elk volgend verzoek. De server verifieert de handtekening bij elk verzoek: als die geldig is, worden de claims van het token vertrouwd; als het token is gemanipuleerd, klopt de handtekening niet meer en wordt het verzoek geweigerd. JWT's bestaan uit drie delen die in Base64URL zijn gecodeerd en gescheiden door punten: de header geeft het ondertekeningsalgoritme aan (HS256 voor HMAC-SHA256, RS256 voor RSA, ES256 voor ECDSA, none voor niet-ondertekende tokens, wat gevaarlijk is en wat u moet weigeren); de payload bevat de daadwerkelijke claims (standaardclaims zoals 'sub' voor het subject, 'exp' voor de vervaldatum, 'iat' voor de uitgiftedatum, plus eventuele aangepaste claims die uw applicatie definieert); de handtekening is het bewijs dat de header en de payload zijn ondertekend door iemand die het geheim bezat. Deze decoder toont de eerste twee delen, die openbare informatie zijn; de handtekening kan alleen met de sleutel worden geverifieerd, en daarom toont elke JWT-decoder de claims zonder verificatie.

Veelvoorkomende toepassingen

  • Debug authenticatieproblemen door de JWT te decoderen die je client verstuurt – zie precies welke claims aanwezig zijn, wie hem heeft uitgegeven en wanneer hij verloopt.

  • Inspecteer API-gateway-JWT's (AWS Cognito, Auth0, Okta) om de claimstructuur voor downstream-services te begrijpen.

  • Controleer of aangepaste claims (organisatie-ID, rol, feature flags) correct worden ingesteld in de code die het token uitgeeft.

  • Vergelijk tokens voor en na een vernieuwing om te bevestigen dat de vervaltijd is verlengd.

  • Controleer het algoritme van een token – bevestig dat in productie RS256 of ES256 wordt gebruikt, nooit 'none'.

  • Vertaal base64url-payloads uit serverlogs naar leesbare claims.

Veelgestelde vragen

Is het veilig te gebruiken met productie-JWT's?
Ja. De decodering vindt volledig in uw browser plaats via lokale JavaScript: het token bereikt nooit onze servers en verschijnt in geen enkel logboek. U kunt dit controleren door DevTools → tabblad Netwerk te openen terwijl u decodeert: er wordt geen enkel uitgaand verzoek geactiveerd. Dat gezegd hebbende: behandel JWT's als inloggegevens en plak ze niet in URL's, schermafbeeldingen of gedeelde documenten, ongeacht waar de decoder draait.
Verifieert dit de handtekening?
Nee. Handtekeningverificatie vereist het geheim (voor HS256) of de openbare sleutel (voor RS256/ES256/PS256). Webtools die om uw geheim vragen om een JWT te verifiëren, zijn een veiligheidsalarmsignaal: u zou dan uw ondertekeningssleutel naar een onbekende sturen. Verifieer handtekeningen op de server of met een bibliotheek die u zelf beheert (jose, jsonwebtoken).
Wat gebeurt er als mijn JWT is verlopen?
De vervaldatum verhindert de decodering niet: de claim 'exp' is slechts een gegeven binnen de payload. Zoek naar 'exp' in de gedecodeerde payload: dat is een Unix-tijdstempel (seconden sinds 1970). Zet die om met onze Tijdstempelconverter om de vervaldatum in uw tijdzone te zien. Als 'exp' al voorbij is, wordt het token geweigerd door elke conforme verifier, ook al blijft de decoder het lezen.
Kunnen JWT's worden versleuteld?
Ja: dat heet JWE (JSON Web Encryption, RFC 7516). Deze tool verwerkt JWS (JSON Web Signature, het gangbare geval), waarbij de payload is ondertekend maar zichtbaar is. JWE-tokens hebben 5 delen gescheiden door punten in plaats van 3 en vereisen de privésleutel van de ontvanger om te worden ontsleuteld. Als uw token 5 delen heeft, hebt u een tool nodig die JWE ondersteunt.
Wat betekent 'alg': 'none' en is dat gevaarlijk?
'none' betekent dat er geen handtekening is: het token is niet ondertekend en iedereen kan elke claim vervalsen. Productiesystemen moeten tokens met 'alg: none' expliciet weigeren. Sommige bibliotheken accepteren ze standaard (een bekende CVE-klasse). Sta altijd alleen de algoritmen toe die uw applicatie verwacht.
Waarom JWT's gebruiken in plaats van sessiecookies?
JWT's zijn staatloos: de server hoeft geen sessie te raadplegen; het token zelf bevat de identiteit en de machtigingen van de gebruiker. Daardoor zijn JWT's ideaal voor gedistribueerde systemen en API's. Sessiecookies hebben een status (ze vereisen sessieopslag op de server) maar zijn eenvoudiger ongeldig te maken (de sessie verwijderen volstaat). De afweging: JWT's schalen beter, maar u kunt een gebruiker niet 'uitloggen' totdat het token vervalt.
Wat zijn de standaardclaims van een JWT?
RFC 7519 definieert: iss (uitgever), sub (subject, meestal de gebruikers-ID), aud (doelgroep), exp (vervaltijd), nbf (niet voor), iat (uitgegeven op), jti (JWT-ID). Daarnaast voegen applicaties aangepaste claims toe zoals 'roles', 'permissions' of 'tenant_id'. Houd de aangepaste claims klein: JWT's reizen in de header van elk verzoek mee en verhogen uw bandbreedteverbruik.

Gerelateerde tools