Over de JWT Decoder
Deze gratis JWT-decoder leest een JSON Web Token en toont de header en de payload als opgemaakte JSON, waarbij de uitgifte- en vervaltijden worden omgezet naar leesbare datums.
Het decoderen gebeurt in uw browser — uw token wordt nooit geüpload. Dat is geen bijzaak: een JWT is meestal een actieve inloggegeven, en wie er een plakt in een website die hem ergens naartoe stuurt, geeft alle toegang weg die erin zit.
Deze tool decodeert een token. Hij controleert de handtekening niet — hieronder leest u waarom dat onderscheid ertoe doet.
De drie delen van een token
Een JWT bestaat uit drie blokken Base64url, gescheiden door punten:
xxxxx.yyyyy.zzzzz
Header — welk algoritme het token heeft ondertekend en welk type het is. Meestal twee velden: alg en typ.
Payload — de claims. Over wie het token gaat, wie het heeft uitgegeven, wanneer het verloopt en wat de applicatie er verder in heeft gezet: gebruikers-ID, e-mail, rollen, rechten, tenant.
Handtekening — een cryptografische controle over de eerste twee delen, gemaakt met een geheim of een privésleutel. Zij bewijst dat het token sinds de uitgifte niet is gewijzigd.
Het wezenlijke punt: de eerste twee delen zijn niet versleuteld. Ze zijn slechts gecodeerd, en iedereen kan ze lezen. Plak een token op deze pagina en de inhoud verschijnt meteen. Base64url is een manier om gegevens veilig in een URL of header te zetten, geen manier om ze te verbergen.
Wat dat betekent voor wat u in een token zet
Omdat de payload leesbaar is voor iedereen die het token heeft, volgt de regel er rechtstreeks uit: zet nooit iets geheims in een JWT.
Wat niet in een payload hoort: wachtwoorden, API-sleutels, creditcardgegevens, burgerservicenummers, medische informatie, alles wat onder privacywetgeving valt. Dat alles is leesbaar voor de gebruiker, voor alles wat het verzoek logt, en voor iedereen die het token bemachtigt.
Wat er wel in hoort: een gebruikers-ID, een rol, een vervaltijd, een uitgever, een doelgroep — identificaties en claims die bedoeld zijn om gezien te worden door het ontvangende systeem.
De handtekening beschermt de integriteit, niet de vertrouwelijkheid. Zij garandeert dat niemand het token heeft veranderd. Zij belet niemand het te lezen.
Decoderen is niet verifiëren
Dit is het onderscheid dat echte beveiligingsfouten veroorzaakt, dus precisie loont.
Decoderen pakt het Base64url uit en toont u de JSON. Het vergt geen sleutel, iedereen kan het, en het bewijst helemaal niets over de echtheid van het token.
Verifiëren berekent de handtekening opnieuw met het geheim of de publieke sleutel en controleert of die overeenkomt. Alleen dat vertelt u dat het token werkelijk is uitgegeven door wie het beweert en niet is gemanipuleerd.
Een token kan perfect decoderen en toch een volledige vervalsing zijn. Iedereen kan een JWT maken dat "role": "admin" zegt en het wordt hier keurig weergegeven — want weergeven is alles wat er gebeurt.
Deze tool verifieert bewust niet, en dat is de veilige keuze: verifiëren vereist het ondertekeningsgeheim, en uw ondertekeningsgeheim in een webpagina plakken zou veel gevaarlijker zijn dan een token plakken. Verifiëren hoort op uw server, met uw sleutel, met een deugdelijke bibliotheek.
De historische versie van deze fout is de alg: none-aanval. Vroege JWT-bibliotheken eerbiedigden een header die beweerde dat er geen algoritme was gebruikt en accepteerden het token ongeverifieerd. Een aanvaller kon de payload aanpassen, alg op none zetten en zo naar binnen lopen. Moderne bibliotheken weigeren dat, maar het is de reden waarom u het verwachte algoritme altijd moet vastleggen in plaats van de header te geloven.
De standaardclaims lezen
De meeste korte veldnamen in een payload zijn geregistreerde claims met een vaste betekenis:
- exp — vervaltijd. Daarna hoort het token te worden geweigerd.
- iat — issued at, uitgegeven op. Wanneer het is aangemaakt.
- nbf — not before, niet vóór. Het token is tot dat moment ongeldig.
- sub — subject. Meestal de gebruikers-ID.
- iss — uitgever. Wie het token heeft gemaakt.
- aud — doelgroep. Voor welke dienst het bedoeld is.
- jti — token-ID, gebruikt voor intrekkingslijsten.
exp, iat en nbf zijn Unix-tijdstempels — seconden sinds 1 januari 1970 — en daarom zien ze eruit als een betekenisloos getal van tien cijfers. Deze tool zet ze om naar leesbare datums, wat meestal de snelste manier is om de vraag te beantwoorden die u hier bracht: *is dit token verlopen?*
Zo gebruikt u hem
- Plak uw JWT (de tekenreeks xxxxx.yyyyy.zzzzz)
- Lees hieronder de gedecodeerde header en payload
- Kopieer een van beide delen als u het nodig hebt
Goed om te weten
- Behandel een token als een wachtwoord. Zolang het geldig is, kan iedereen die het heeft optreden als die gebruiker. Plak geen actieve tokens in tools die ze uploaden en plaats ze niet in een ticket of chat.
- JWT's zijn lastig in te trekken. Ze zijn geldig tot ze verlopen, dus een gestolen token werkt tot dat moment, tenzij u een blokkeerlijst bijhoudt. Daarom zijn korte vervaltijden belangrijk.
- Bearer hoort niet bij het token. Verwijder dat voorvoegsel uit een Authorization-header voordat u decodeert.
- Base64url is geen standaard-Base64. Het gebruikt - en _ in plaats van + en / en laat de =-opvulling meestal weg, waardoor een JWT-blok kan mislukken in een gewone Base64-decoder.
- Klokverschillen veroorzaken verwarrende fouten. Een token kan er voor u geldig uitzien en toch geweigerd worden door een server waarvan de klok een minuut of twee afwijkt.
- Een JWT is geen sessie. Het draagt zijn claims met zich mee, dus wijzigingen in de rol van een gebruiker gaan pas in als het token verloopt.
Veelgestelde vragen
Is een JWT versleuteld?
Nee. De header en de payload zijn Base64url-gecodeerd, waardoor ze veilig in een URL of HTTP-header passen, maar dat verbergt ze niet. Iedereen die het token heeft, kan elke claim erin lezen, zoals deze pagina laat zien. De handtekening beschermt het token tegen wijziging, niet tegen lezen.
Controleert deze tool de handtekening?
Nee, en dat met opzet. Verifiëren vereist het ondertekeningsgeheim of de publieke sleutel, en uw ondertekeningsgeheim in een webpagina plakken zou aanzienlijk gevaarlijker zijn dan een token plakken. Verifiëren hoort op uw server met een deugdelijke bibliotheek. Deze tool decodeert en toont u de inhoud, en dat is wat u nodig hebt bij het debuggen.
Is het veilig om mijn token hier te plakken?
Hier wel — het decoderen gebeurt volledig in uw browser en er wordt niets verzonden, dus u kunt de internetverbinding verbreken en het werkt nog steeds. Wees in het algemeen wel voorzichtig met tools. Een actief JWT is een werkend inloggegeven, en een site die het naar een server stuurt, heeft zojuist alle toegang gekregen die het verleent.
Hoe weet ik of mijn token is verlopen?
Kijk naar de claim exp, een Unix-tijdstempel in seconden. Deze tool zet die om naar een leesbare datum en vertelt u direct of dat moment voorbij is. Lijkt een token u geldig terwijl een server het weigert, controleer dan het klokverschil — een verschil van een of twee minuten tussen machines is al genoeg.
Wat betekenen sub, iss, aud en iat?
Het zijn geregistreerde claims met standaardbetekenissen: sub is het subject, normaal gesproken de gebruikers-ID; iss is de uitgever die het token heeft gemaakt; aud is de beoogde doelgroep, dus welke dienst het zou moeten accepteren; iat is wanneer het is uitgegeven. Samen met exp en nbf dekken ze het wie, waar en wanneer.
Waarom mislukt mijn JWT in een gewone Base64-decoder?
Omdat een JWT Base64url gebruikt, een variant die + vervangt door - en / door _ en meestal de =-opvulling weglaat. Die vervangingen bestaan zodat de waarde veilig in een URL past. Zet u de tekens terug, dan decodeert het wel in een standaard Base64-tool.
Kan ik een JWT-payload bewerken?
U kunt de tekst wijzigen, maar het resultaat wordt geweigerd door elke correct geïmplementeerde server, omdat de handtekening niet meer past bij de gewijzigde inhoud. Daar dient de handtekening precies voor. Tokens worden opnieuw uitgegeven door de dienst die ze ondertekent, niet met de hand aangepast.
Gerelateerde tools
- Base64 coderen / decoderen — de codering waarin de drie blokken zijn geschreven
- JSON-formatter — de gedecodeerde payload opschonen en bekijken
- Hash-generator — de hashfuncties onder de handtekening
