JWT Decoder Online: decodeer, inspecteer en begrijp uw tokens daadwerkelijk

Afgelopen voorjaar werden gebruikers afgemeld bij Toolz.dev. Niet soms - constant Aanmelden, klik op één tool, boem: terug naar het inlogscherm De backend geeft 15-minuten toegangstokens en 7-dagen verversingstokens uit, en I'd testte die stroom honderd keer Dus natuurlijk ging ik ervan uit dat het verversingseindpunt kapot was en besteedde ik een uur en veertig minuten aan het lezen van Express middleware die er niets mis mee had.

Toen deed ik eindelijk het voor de hand liggende ding. Ik pakte een live toegangsfiche uit de autorisatiekop, plakte het in een decoder en keek naar de claims. de exp was goed. de iat was prima Het token was nog 14 minuten geldig Wat betekende dat de server in orde was - en de bug moest op de client zitten Zeker: mijn frontend was aan het controleren payload.exp < Date.now(). exp is seconden sinds tijdperk. Date.now() is milliseconden Elk vers geslagen token zag eruit alsof het ergens rond 1970 was verlopen, dus de client & quot;helpfully" logde iedereen uit voordat de server ooit inspraak kreeg Drie karakters van fix - /1000- na bijna twee uur jagen.

Dat' is de hele toonhoogte voor het hebben van een JWT decoder in je gereedschapskist Een JWT ziet eruit als lijnruis - drie brokken base64url gebrabbel aan elkaar gelijmd met stippen - maar het ' s gewoon JSON met een trenchcoat op het moment dat je de claims kunt lezen, de helft van je auth bugs stoppen met mysteries Verkeerd publiek, verlopen token, ontbrekende rol, klok scheef, milliseconden-vs-seconden - ze ' zitten allemaal precies daar in platte tekst zodra je decodeert.

Maar - en dit maakt uit - waar je decodeert is geen neutrale keuze Een echt toegangstoken is een live-referentie Plak het in een decodersite die tokens naar een server verzendt, en jij & #39; heb zojuist een werkende sleutel van je API in een vreemde gedeponeerd& #39; s request logs. Dat' is de specifieke reden waarom ik de Toolz.dev JWT-decoder volledig in uw browser te draaien. Daarover meer hieronder.

tl;dr: Om een JWT online te decoderen, plakt u deze in de Toolz.dev JWT-decoder- het splitst header, payload en handtekening onmiddellijk, vertaalt exp/iat into human dates, en draait 100% client-side zodat het token nooit uw machine verlaat Eén ding om in het geheugen te branden: decoderen is NIET verifiëren Een JWT is gewoon base64url-gecodeerde JSON die iedereen kan lezen - alleen handtekeningverificatie met de sleutel bewijst het ' s betrouwbaar.

Belangrijkste kenmerken

Instant header, payload en handtekening split

Plak een token en de decoder breekt het onmiddellijk in zijn drie delen: de header (algoritme en tokentype), de payload (uw claims) en de handtekening (links gecodeerd, omdat het & # 39; een onbewerkte MAC of handtekening is - there& # 39; is daar niets voor mensen leesbaars).Geen verzendknop, geen pagina herladen. Dit weerspiegelt precies wat uw auteursbibliotheek intern doet vóór verificatie: split on ., base64url-decodeer de eerste twee segmenten, parseer als JSON. De naast elkaar gelegde onderdelen zien is de snelste manier om intuïtie voor het formaat op te bouwen Na enkele tientallen tokens, u & #39; zal beginnen met het herkennen van een RS256 Auth0-token versus een HS256 Laravel-token in één oogopslag - de header geeft het elke keer weg.

Door mensen leesbare EXP, IAT en NBF tijdstempels

De meest handige functie, punt uit. exp, iat, en nbf zijn NumericDate-waarden - seconden sinds het Unix-tijdperk - en niemand, inclusief ikzelf, kan lezen 1783430700 En vertel je of dat aanstaande dinsdag of de hittedood van het universum is. De decoder converteert elke keerstempelclaim in een werkelijke datum en tijd, in uw lokale tijdzone en UTC. Dit is waar de klassieke bug van milliseconden-vs-seconden direct zichtbaar wordt: als je gedecodeerd bent exp render als een datum in het jaar 56.000-iets, iemand heeft een javascript gevuld Date.now() in een veld dat seconden verwacht. Ik heb die bug verzonden. Het zien van de absurde datum is de diagnose. Voor een diepere archeologie van de tijdstempel, tijdstempel converter is één tabblad verwijderd.

Aftellen en status

Naast het weergeven van de datum, vertelt de decoder u de huidige status van het token: geldig, verlopen of nog niet actief (wanneer nbf is in de toekomst).Als de token's nog in leven is, krijg je een aftelling naar vervaldatum Dit klinkt als een klein gemak totdat u ' opnieuw een intermitterende 401 debuggen en & quot; was dit specifieke token dood toen het verzoek werd afgevuurd? & quot; keer op keer Het vergelijken van het aftellen met uw server 's geconfigureerde TTL vangt ook snel een verkeerde configuratie op - als uw toegangstokens 15 minuten zouden duren en het aftellen 6 dagen zegt, leest uw uitgiftecode de verkeerde configuratiewaarde.

Algoritme en header-inspectie

De gedecodeerde koptekst toont u alg en typ (plus) kid en vrienden wanneer aanwezig), die vragen beantwoordt die belangrijk zijn voor de beveiliging, niet alleen voor het debuggen. Is dit token HS256 of RS256? doet de kid Match een sleutel die uw JWKS-eindpunt daadwerkelijk bedient? En de grote: is alg iets wat het nooit zou moeten zijn, zoals none? Tokens die claimen "alg": "none" zijn of testopstellingen of iemand die uw verificateur onderzoekt - hoe dan ook, u wilt het onmiddellijk zien Ik controleer eerst de header op elk onbekend token, voordat ik een enkele claim lees.

Syntaxis-gemarkeerde, geformatteerde JSON-claims

Rauwe payloads zijn JSON-blobs met één regel, en identiteitsproviders houden ze graag in: geneste objecten, naamruimte met aangepaste claims, arrays met scopes. De decoder drukt alles mooi af met syntaxis markeren dus roles, scope, aud Arrays en geneste toestemmingsobjecten zijn eigenlijk scanbaar. Het is dezelfde behandeling als JSON-formatter geeft willekeurige JSON, automatisch toegepast op uw claims Wanneer u ' vergelijkt u twee tokens - bijvoorbeeld één van een gebruiker die toegang heeft tot een eindpunt en één van een gebruiker die kan ' t - geformatteerde uitvoer verandert een scheelziende oefening in een diff van tien seconden.

100% clientzijde - uw token verlaat nooit de browser

Dit is de functie waar I'd voor vecht Een geplakt toegangstoken is geen voorbeeldgegevens - it' is een live-referentie die zich authenticeert als een echte gebruiker totdat exp. Elke decoder die uw token naar een backend plaatst, heeft zojuist een werkende sleutel in serverlogboeken, Analytics, misschien een fouttracker van derden geschreven. De Toolz.dev-decoder doet alle decodering in JavaScript, op uw tabblad. Er wordt niets doorgegeven, niets wordt opgeslagen. Geloof me niet op mijn woord: open devtools, bekijk het tabblad Netwerk, plak een token. nul verzoeken. Ik schreef waarom deze architectuur van belang is voor elke tool voor gevoelige invoer in Mijn stuk over gegevensprivacy in online tools.

Werkt met elke JWT, vanaf elke stapel

JWT's zijn een standaard - RFC 7519- dus de decoder doet ' het maakt niet uit wie de jouwe heeft geslagen Auth0- en Firebase-tokens met hun op naam gespatieerde aangepaste claims, aan Laravel Sanctum aangrenzende opstellingen, Keycloak, Supabase, AWS Cognito of de met de hand gerolde HS256-tokens mijn eigen Express-backend-borden voor Toolz.dev - als het ' drie basis64url-segmenten zijn verbonden door punten, decodeert het. Dat omvat misvormde bijna-JWT's: als segment twee won' ontleed als JSON, de de de decoder vertelt je welk deel wordt gebroken in plaats van falend#, wat zelf meer diagnostisch is.

Hoe de JWT-decoder te gebruiken

Stap 1: Pak het token

Vind het token waar uw app het ook bewaart. Meest: DevTools → Netwerktab → Klik op een verzoek → Kopieer de Authorization: Bearer eyJ... headerwaarde (zonder het woord & quot; Bearer") Of controleer Application → Local Storage / Cookies, aangezien tal van apps daar tokens opslaan Op de backend log het of trek het uit je test suite Kopieer de hele string - een JWT die zijn laatste paar tekens nog steeds decodeert maar nooit zal verifiëren, en dat' is een verwarrend uur dat je niet hebt ' niet nodig.

Stap 2: Plak het in

Open de JWT-decoder en plakken. Decoderen gebeurt terwijl u typt - geen knop Als u ' nerveus bent over het plakken van een productietoken waar dan ook (goed instinct), open dan eerst het tabblad Netwerk en bevestig dat er niets wordt verzonden Het is 't. Die paranoiacontrole duurt tien seconden en het ' is precies wat I'd met iemand anders doet 's tool.

Stap 3: Lees de drie delen

Koptekst eerst: Bevestig alg is wat uw systeem verwacht en typ is JWT. Dan de laadstroom: iss (wie heeft het geslagen), aud (voor wie is het), sub (welke gebruiker), plus welke rollen, scopes of aangepaste claims uw stack toevoegt. De handtekening blijft gecodeerd - it's cryptografische uitvoer, geen gegevens. Als de header zegt none, Stop en ga naar de toelatingslijst van uw verificateur voordat u iets anders doet.

Stap 4: Controleer exp en de beweringen die bijten

Kijk naar de gedecodeerde exp datum en de vervalstatus. Verlopen? Er is uw 401. Geldig maar toch afgewezen? Vergelijk nu aud en iss tegen uw verificateur's config - mismatches zijn er de op een na meest voorkomende oorzaak na het verstrijken. En als een tijdstempel een jaar van vijf cijfers oplevert, gefeliciteerd: u ' Ik heb een bug van milliseconden versus seconden gevonden en ik heet u hierbij welkom bij een zeer grote club.

Wat zit er eigenlijk in een JWT? Anatomie van de drie delen

Een JSON-webtoken, gedefinieerd in RFC 7519, is drie met Base64URL gecodeerde segmenten die zijn verbonden door perioden: header.payload.signature. (Strikt genomen is de ondertekende variëteit een JWS volgens RFC 7515 - there' is een gecodeerde neef, JWE, maar bijna elk token dat je ' in het wild ontmoet, is een ondertekende JWS.)

Het sleutelwoord is gecodeerd. Base64url is een transportcodering - een omkeerbare manier om bytes URL-veilig te maken - geen codering Iedereen die een JWT vasthoudt, kan alles in de header en payload lezen met nul sleutels, nul geheimen, nul inspanning Speel met de raw codering in de Base64-converter En je ziet het is het standaard alfabet met + en / gewisseld voor - en _, opvulling viel. Ik schreef meer over de codering zelf in de Base64-coderingsgids.

Decodeer een typische header en je krijgt:

{ "alg": "HS256", "typ": "JWT" }

En een payload opgebouwd uit de geregistreerde claims RFC 7519 definieert:

{
  "iss": "https://toolz.dev",
  "sub": "user_8f3a2c",
  "aud": "toolz-api",
  "exp": 1783431600,
  "nbf": 1783430700,
  "iat": 1783430700,
  "jti": "b4d1f0e2"
}

iss is de uitgever, sub het onderwerp (meestal uw gebruikers-ID), aud het beoogde publiek, jti Een unieke token-ID. exp, nbf, en iat zijn numerieke waarden: tweede soort Sinds het UNIX-tijdperk. Geen milliseconden. JavaScript's Date.now() Retourneert milliseconden en het verwarren van de twee produceert tokens die onmiddellijk verlopen (mijn Toolz.dev-logboekbug) of tokens met exp data in het jaar 56.000 die feitelijk nooit verlopen - wat stilletjes de gevaarlijkere mislukking is.

HS256 versus RS256. HS256 tekent bij een HMAC over een gedeeld geheim - snel, eenvoudig, maar elke dienst die tokens verifieert, houdt ook het geheim vast, en iedereen die het geheim bewaart, kan dat munt penningen. Prima voor een monoliet als mijn backend, waar uitgever en verificateur hetzelfde proces zijn. RS256 tekent met een privésleutel en verifieert met een openbare, zodat u de openbare sleutel (via JWKS) kunt publiceren en een tiental microservices kunt verifiëren zonder dat een van hen kan vervalsen. Gedistribueerde systemen en ontheemden van derden moeten op RS256 of zijn ECDSA/EDDSA-broers en -zussen staan.

de alg: none aanval. RFC 7519 staat onbeveiligde JWTS toe waar alg is none En de handtekening is leeg. Vroege bibliotheken vertrouwden de headers39;s alg Blindelings, dus aanvallers onttrokken de handtekening, set alg tegen none, en zeilde door verificatie met volledig door aanvallers gecontroleerde claims. Een gerelateerde truc swaps RS256 voor HS256, zodat de verificateur de openbaar sleutel als HMAC geheim Dit is de reden waarom RFC 8725 - JSON Web Token Best Current Practices - bot is: de verificateur moet zijn toegestane algoritmen in code pinnen en het token nooit laten kiezen Als uw bibliotheekaanroep dat doet't een expliciete algorithms Lijst, repareer dat vandaag.

Decoderen versus verifiëren - de regel die er toe doet. Decoderen is lezen; verifiëren is vertrouwen. Het verschil in code:

// Decoding: no secret, no trust. Anyone can do this.
const payload = JSON.parse(
  Buffer.from(token.split('.')[1], 'base64url').toString()
);

// Verifying: proves the signature AND pins the algorithm.
const verified = jwt.verify(token, secret, { algorithms: ['HS256'] });

Een online decoder doet het eerste Het kan u de claims tonen; het kan niet - en mag niet pretenderen - u vertellen dat het token authentiek is Alleen verify, met de sleutel, doet dat. Neem nooit autorisatiebeslissingen van gedecodeerde maar niet-geverifieerde claims.

Wat leidt tot de laatste regel: Zet nooit geheimen in een JWT-payload. Geen wachtwoorden, geen API-sleutels, geen gegevens u'd let op een aanvaller lezen De payload is openbaar door de bouw - ondertekend tegen manipulatie, wijd open voor lezen Als het ' s in het token, neem aan dat het hele internet het kan zien.

Veelvoorkomende gebruiksgevallen

Debugging 401s tijdens API-ontwikkeling

De 401 is de minst informatieve statuscode in HTTP De server zei nee - maar was het token verlopen? Verkeerd publiek? ondertekend met een verouderde sleutel? geheel ontbrekend omdat je interceptor did't fire? het decoderen van het daadwerkelijke token van het falende verzoek stort de zoekruimte in seconden in De helft van de tijd exp beantwoordt het alleen. de andere helft, vergelijkend iss en aud Tegenover uw verifier vindt u een dev-token die wordt afgespeeld tegen staging, of vice versa. Ik bewaar de decoder naast mijn HTTP-client voor precies deze lus; het is een kerninvoer in mijn API-foutopsporingstoolkit. Decodeer eerst, lees middleware als tweede - de omgekeerde volgorde kostte me één keer een uur en veertig minuten, en ik ben van plan om interesse voor die les te blijven verzamelen.

Verrassingslogo's uitleggen

Wanneer gebruikers melden "Het blijft me uitloggen", de tijdstempels van het token zijn uw getuigenverklaring. Decodeer een nieuw toegangstoken en controleer de kloof tussen iat en exp- zijn het eigenlijk de 15 minuten die u hebt geconfigureerd, of heeft een env var het overschreven naar 60 seconden? Controleer vervolgens of het vernieuwingstoken's 7-dagenvenster is wat u denkt dat het is. Klokscheef verschijnt hier ook: als uw uitgifteserver' De klok loopt een paar minuten snel, tokens arriveren al oud door de client' s afrekening. En natuurlijk kondigt de vergelijkingsbug van seconden tot miljarden seconden - degene die Toolz.dev beet - zichzelf aan op het moment dat je een volkomen geldige fout ziet exp Op een token is uw klant zweert dat hij verlopen is.

Controleren wat uw identiteitsprovider in tokens zet

De meeste teams hebben de tokens nooit echt gelezen, hun IdP-muntjes, en het is ' het waard om te doen. Decodeer er een en je kunt e-mailadressen, volledige namen, afbeeldings-URL's, huurderidentificaties vinden - PII rijdt mee in elk afzonderlijk API-verzoek, opgeslagen in localStorage en leesbaar voor alles wat het token in handen krijgt. Hier' is mijn eigenzinnige standpunt, en I' Ik zal het met iedereen bespreken: don't plaats gebruikers-e-mails in JWT-payloads. De sub Claim bestaat precies, zodat u een ondoorzichtige identificatiecode kunt dragen en de server-side menselijke details kunt opzoeken. Elke extra claim is gegevens die u uitzendt en bytes die u betaalt voor elk verzoek. Decodeer, controleer en snijd dan de claimtoewijzingen van uw IDP in.

Verifiëren van rollen en scopes tijdens het debuggen van autorisatie

Authenticatie zegt wie je bent; autorisatie zegt wat je kunt doen - en wanneer autorisatie zich misdraagt, staat het antwoord in de claims Gebruiker zweert ze' zijn een admin maar krijgt 403s? decodeer hun token Als role zeggen user, het token is geslagen vóór de promotie en ze moeten opnieuw inloggen - een klassiek gevolg van staatloze tokens met verouderde snapshots Als de rol aanwezig is maar de toegang nog steeds mislukt, controleer dan de exacte naam en vorm van de claim: roles versus Amerikaans wagen role, array versus string, scope Als een ruimte-gescheiden string VS scp als een array. Middenwerkcontrole payload.roles.includes('admin') tegen een laadvermogen dat role: "admin" faalt geruisloos en woedend Twee gedecodeerde tokens naast elkaar - één werkend, één niet - regelen het meestal binnen een minuut.

Toegangs- en vernieuwing tokeninhoud vergelijken

In een dual-token-opstelling zoals de mijne, zouden de twee tokens er zinvol anders uit moeten zien, en beide decodering is de audit. Het toegangstoken: kort exp, plus wat de API ook beweert per verzoek. Het vernieuwingstoken: lang exp, een jti voor het traceren van herroepingen, en zo dicht mogelijk bij niets anders Als uw refresh-token rollen en profielgegevens bevat, is er iets's uitgeschakeld - it's slechts aan één eindpunt gepresenteerd en zou ' t de toegangstoken moeten dupliceren' s taak Deze side-by-side controle vangt ook de gênante bugklasse op waarbij beide tokens per ongeluk dezelfde TTL krijgen, waardoor uw & quot; 15 minuten toegangvenster & quot; in beveiligingstheater wordt geplaatst Vraag me hoe ik weet om dat te controleren.

JWT versus ondoorzichtige sessietokens: een eerlijke vergelijking

Ik gebruik JWTS voor Toolz.dev en ik zal je nog steeds vertellen dat ze te veel voorgeschreven zijn. Het intrekkingsverhaal is echt slecht: wanneer je een gebruiker verbiedt, blijft hun toegangstoken werken tot exp- en dat is precies de reden waarom mijn toegangstokens 15 minuten leven en het 7-daagse refresh-token is wat ik kan doden server-side Die hybride is het eerlijke patroon: kortstondige staatloze JWT's voor goedkope verificatie, één stateful checkpoint voor controle Als je' bezig met het uitvoeren van een monoliet met één database, gewone sessies zijn eenvoudiger, kleiner en direct herroepbaar - de JWT' s superkracht van gedistribueerde verificatie is het oplossen van een probleem dat je don't hebt.

Terwijl wij' in één oogopslag vergelijken - HS256 vs RS256:

Veelgestelde vragen

Is het veilig om een jwt in een online decoder te plakken?

Alleen als de decoder client-side draait Een echt token is een live credential - het verzenden naar iemand' s server plant een werkende sleutel in hun logs De Toolz.dev JWT Decoder doet alle decodering in uw browser en verzendt niets; u kunt dit zelf bevestigen door het tabblad Netwerk te bekijken terwijl u plakt Voor decoders kunt u ' t alleen verlopen of testtokens verifiëren, gebruiken.

Kun je een JWT decoderen zonder het geheim?

Ja - dat' is het punt dat mensen het meest missen De header en payload zijn base64url-gecodeerde JSON, en codering is geen encryptie Iedereen kan elke claim lezen zonder enige sleutel Het geheim (of privésleutel) is alleen nodig om de handtekening te maken of te decoderen vereist niets; vertrouwen vereist verificatie.

Wat is het verschil tussen decodering en het verifiëren van een JWT?

Decodering leest de inhoud: Splitsen op stippen, base64url-decode, ontleden JSON. Verifiëren bewijst echtheid: bereken of controleer de handtekening met de geheime of openbare sleutel, bevestig het algoritme, controleer de vervaldatum. Een decoder laat zien wat een token beweert; alleen verificatie, server-side met de sleutel, vertelt je of je het moet geloven. Autoriseer nooit op basis van gedecodeerde maar niet-geverifieerde claims.

Waarom wordt mijn JWT weergegeven als ongeldig of verlopen?

Meestal zijn de exp echt geslaagd is - decodeer het en controleer de datum Volgende verdachten: een afgeknot token van een slordige copy-paste, een aud of iss Dat komt niet overeen met de configuratie van uw verificateur, klokschudding tussen servers of een handtekening van een gedraaide sleutel. Als de gedecodeerde exp Ziet er goed uit, maar uw code verwerpt het token, controleer of u seconden vergelijkt met milliseconden.

Zijn JWTS versleuteld?

Standaard JWT's - technisch gezien JWS, per RFC 7515 - zijn ondertekend, niet versleuteld De handtekening detecteert geknoei maar verbergt niets; de payload is leesbaar voor iedereen Een versleutelde variant (JWE) bestaat maar is zeldzaam in typische web auth Praktische regel: behandel elke JWT payload als openbaar, en zet nooit wachtwoorden, API sleutels, of gevoelige gegevens in een.

In welk formaat is de EXP-claim?

exp is een numeriekdatum: seconden sinds het UNIX-tijdperk (1 januari 1970 UTC), zoals gedefinieerd in RFC 7519. Hetzelfde voor iat en nbf. De klassieke bug gebruikt JavaScript's Date.now(), die milliseconden retourneert - tokens produceren die er onmiddellijk verlopen uitzien of vervaldata rond het jaar 56.000 bevatten. Als een gedecodeerde tijdstempel een jaar van vijf cijfers aangeeft, zal & # 39; is jouw bug.

Wat is de Alg None-aanval?

RFC 7519 maakt onbeveiligde JWTS mogelijk met "alg": "none" En een lege handtekening. Oude bibliotheken vertrouwden het veld van het algoritme van de kopbal, dus aanvallers onttrokken handtekeningen, set alg tegen none, en doorgegeven verificatie met vervalste claims. RFC 8725, de beste huidige praktijken van JWT, vereist dat verificateurs een expliciete toelatingslijst van algoritmen in code vastzetten en negeren wat het token vraagt.

Moet ik HS256 of RS256 gebruiken?

HS256 gebruikt één gedeeld geheim voor ondertekening en verificatie - eenvoudig en snel, rechts voor een enkele dienst die zowel zijn eigen tokens uitgeeft als controleert RS256 tekent met een privésleutel en verifieert met een openbare, zoveel diensten kunnen verifiëren zonder te kunnen vervalsen Vuistregel: monoliet, HS256; microservices of externe identiteitsprovider, RS256.

inpakken

ik bouwde de JWT-decoder omdat ik het steeds nodig had tijdens het bouwen van Toolz.dev zelf - dezelfde 15 minuten toegangstokens en 7-dagen refresh tokens I' zijn ontleed in deze gids Het decodeert direct, vertaalt de tijdstempels die 90% van de verwarring veroorzaken, en stuurt nooit uw token ergens Dat laatste deel is't een functie-checkbox; voor een tool die live inloggegevens verwerkt, it's het hele ontwerp.

Als tokens deel uitmaken van uw dagelijkse debugging, zullen de buren ook hun brood verdienen: de tijdstempel converter Voor de archeologie van het tijdperk, de Base64-converter Voor het porren in rauwe segmenten, JSON-formatter voor claims, en de Hash-generator Wanneer je met digests werkt. Voor de bredere workflow, mijn API-debugger-tools voor debuggen Dekt waar een decoder in de lus past.

En houd de versie van één zin op uw monitor vast: decodering vertelt u wat een token zegt, verificatie vertelt u of u het moet geloven. Verwar de twee en je verzendt het soort bug dat eindigt als de openingsanekdote in iemands blogpost. Deze keer was het van mij.