UltKit

JWT-decoder

Plak een JSON Web Token en lees de header en payload als opgemaakte JSON. Het tijdstip van uitgifte en de vervaldatum ziet u als gewone datums, met een melding of het token op dit moment geldig is. Het decoderen gebeurt volledig in uw browser. Dat is belangrijk wanneer het token een actieve inloggegeven is.

0 tekens · 0 woorden · 0 regels

0 tekens · 0 woorden · 0 regels

Werkt volledig in dit browsertabblad. Uw tekst wordt nooit geüpload of opgeslagen.

Geregistreerde claims

De zeven claimnamen uit RFC 7519 §4.1. Alle zijn optioneel; tijden zijn seconden sinds 1970-01-01 UTC.

ClaimBetekenis
issIssuer: wie het token heeft gemaakt en ondertekend
subSubject: de gebruiker of entiteit waar het token over gaat
audAudience: voor wie het token bedoeld is
expVerlooptijd: wijs het token na dit moment af
nbfNiet vóór: wijs het token af vóór dit moment
iatUitgegeven op: wanneer het token is gemaakt
jtiJWT-ID: unieke identificatie, gebruikt tegen replay

Veelgebruikte alg-waarden

alg-waardeBetekenis
HS256HMAC met SHA-256; één gedeeld geheim ondertekent en verifieert
RS256RSA PKCS#1 v1.5-handtekening met SHA-256; privésleutel ondertekent, publieke sleutel verifieert
PS256RSA-PSS met SHA-256
ES256ECDSA op de P-256-curve met SHA-256; korte handtekeningen
EdDSAEd25519- of Ed448-handtekeningen
noneNiet-ondertekend token; servers horen het af te wijzen

Hoe een JSON Web Token is opgebouwd

JWT is vastgelegd in RFC 7519 (mei 2015), die voorstelt het uit te spreken als het Engelse woord "jot". De gangbare ondertekende vorm bestaat uit drie Base64url-strings die met punten aan elkaar zijn gekoppeld: header.payload.signature. De header noemt in alg het ondertekeningsalgoritme, zoals HS256 of RS256, en vaak in kid een sleutel-ID. De payload bevat claims, JSON-velden zoals sub (de gebruiker), iss (de uitgever), aud (de beoogde doelgroep) en exp, nbf en iat, tijden in seconden sinds 1 januari 1970 UTC. De decoder zet deze drie om naar uw lokale tijd en ISO 8601, en laat zien of het token is verlopen, nog niet geldig is of binnen de geldigheidsperiode valt.

Base64url is een codering, geen versleuteling. Iedereen die een token heeft, kan de payload lezen, precies zoals deze pagina dat doet. Zet daarom nooit wachtwoorden, kaartnummers of andere geheimen in claims. Een token met vijf door punten gescheiden delen is een JWE, een versleuteld token. De inhoud is zonder de sleutel niet te lezen en de decoder meldt dat. Een voorafgaand "Bearer " uit een Authorization-header wordt automatisch verwijderd.

Waarom de handtekening hier niet wordt geverifieerd

De handtekening bewijst dat de header en payload zijn gemaakt door iemand met de sleutel en sindsdien niet zijn gewijzigd. Om dat te controleren hebt u die sleutel nodig: het gedeelde geheim bij HMAC-algoritmen zoals HS256, of de publieke sleutel van de uitgever bij RS256, ES256 of EdDSA. Een productiegeheim in een webpagina plakken is geen goed idee, en een decoder die zonder sleutel doet alsof een token betrouwbaar is, zou schijnzekerheid geven. Deze tool toont daarom de handtekening, maar controleert die niet. Beschouw wat u ziet als een bewering van het token, niet als een feit.

Verificatie hoort op uw server thuis, met een onderhouden bibliotheek waarin het verwachte algoritme vastligt. Twee historische fouten laten zien waarom: het accepteren van alg "none", waarmee iedereen een niet-ondertekend token kan vervalsen, en algoritmeverwarring, waarbij een server die RS256 verwacht ertoe wordt gebracht een HS256-handtekening te controleren met de publieke sleutel als HMAC-geheim. Een decoder is bedoeld voor debuggen: zien welke claims een provider uitgeeft, een verkeerde audience opsporen of ontdekken dat een sessie mislukte omdat exp een minuut geleden verliep. Wilt u de Base64url-segmenten onbewerkt lezen, gebruik dan de Base64-decoder.

Veelgestelde vragen

Is het veilig om een echt toegangstoken in een JWT-decoder te plakken?
Op deze pagina verlaat het token uw browser nooit. Toch werkt een geldig token tot het verloopt als een wachtwoord, dus gebruik liever verlopen of testtokens en houd echte tokens uit screenshots en chats.
Waarom staat mijn token als verlopen terwijl het net is uitgegeven?
Controleer eerst de klok van uw apparaat. Sommige uitgevers geven access tokens een levensduur van slechts enkele minuten, en een token uit een log kan ouder zijn dan het lijkt. Een exp in milliseconden in plaats van seconden doet het omgekeerde en komt duizenden jaren in de toekomst uit.
Kan iemand de payload van mijn JWT wijzigen?
Ze kunnen het aanpassen en opnieuw coderen, maar de handtekening klopt dan niet meer. Een server die handtekeningen controleert met de juiste sleutel en het juiste algoritme wijst het gewijzigde token af.
Wat is het verschil tussen JWS en JWE?
Een JWS (RFC 7515) is ondertekend, heeft drie delen en kan door iedereen worden gelezen. Een JWE (RFC 7516) is versleuteld, heeft vijf delen en alleen de sleutelhouder kan de payload lezen.
Wordt een JWT ongeldig als ik uitlog?
Niet vanzelf. Een ondertekend JWT blijft geldig tot exp, tenzij de server een blokkeerlijst bijhoudt of een sessieregistratie controleert. Daarom krijgen access tokens meestal een korte levensduur.