Ingen uppladdning, 100% lokalt, inget konto

Så gör du

Så avkodar du en JWT utan att läcka den

En JSON Web Token bär verklig data: vilken användare den utfärdades till, vilka behörigheter den ger, när den går ut. Att klistra in en i en slumpmässig avkodare på nätet innebär att du lämnar över den datan, och ofta en fortfarande giltig session, till en server du inte styr över. Avkodaren nedan körs helt i din webbläsare, så du kan läsa vad som finns inuti en token, kontrollera om den har gått ut och bekräfta en HMAC-signatur när du kan hemligheten, allt utan att en enda nätverksbegäran lämnar din flik.

Steg för steg

  1. Öppna JWT-avkodaren och klistra in din token i inmatningsrutan. En JWT består av tre Base64Url-delar sammanfogade med punkter: header, payload och signatur. Du kan klistra in den med prefixet Bearer eller utan; verktyget läser strukturen i båda fallen och säger genast till om formatet är fel.
  2. Läs den avkodade headern och payloaden. Headern visar signeringsalgoritmen (till exempel HS256 eller RS256) och nyckel-id:t när det finns. Payloaden listar dess claims: vem token är till för (sub), vem som utfärdade den (iss) och tidsstämplarna. Verktyget omvandlar de numeriska fälten iat, nbf och exp till läsbara datum och markerar om token fortfarande är giltig eller redan har gått ut.
    En avkodad JWT som visar headerns algoritm och payloadens claims med läsbara datum för utfärdande och utgång
  3. Om token använder HS256 och du har den delade hemligheten, klistra in hemligheten i verifieringsfältet och klicka på Verifiera. Verktyget räknar om HMAC över headern och payloaden och jämför den med signaturen, så att du får veta om token är äkta eller har manipulerats. För RS256- eller ES256-tokens sker signeringen med en privat nyckel som du inte har, så verktyget granskar dess claims men påstår inte att det verifierar signaturen.
    HMAC-verifieringsfältet ifyllt med den delade hemligheten och en bricka för giltig signatur för en HS256-token

Varför du aldrig ska klistra in en token på en slumpmässig sajt

En JWT är inte krypterad. Headern och payloaden är bara Base64Url-kodade, vilket innebär att alla som tar emot token kan läsa varje claim i den: e-post, användar-id, roller, interna flaggor. Om token är en åtkomsttoken som inte har gått ut kan den som har den spela upp den igen och agera som dig tills den gör det. När du klistrar in en levande token i en avkodare på nätet skickar du allt detta till den serverns loggar. Att avkoda token på din egen maskin, utan uppladdning, är det enda sättet att granska den utan att utöka kretsen som kan se den. Du kan bekräfta att det inte sker någon trafik genom att öppna nätverkspanelen medan du avkodar.

Vad signaturen kan och inte kan säga dig

Signaturen är det som hindrar någon från att ändra dess claims och komma undan med det. För en HS256-token signerar och verifierar samma hemlighet, så om du kan hemligheten kan du till fullo bekräfta att token är äkta direkt här. För RS256- och ES256-tokens signerar en privat nyckel token och bara den matchande publika nyckeln verifierar den; den privata nyckeln lämnar aldrig utfärdaren, så ett verktyg på klientsidan kan läsa dess claims men kan inte ärligt bevisa signaturen utan den publika nyckeln. Behandla den avkodade payloaden som ett påstående från utfärdaren, inte som bevis, tills signaturen har kontrollerats av den som äger verifieringsnyckeln. För att hasha eller jämföra hemligheter separat körs hashgeneratorn på denna sajt också lokalt.

JWT-struktur och vad varje del avslöjar

En JWT består av tre Base64url-kodade segment separerade med punkter: header, payload och signatur. Headern deklarerar tokentypen ("JWT") och algoritmen: HS256 (HMAC-SHA-256, en delad hemlighet) eller RS256 (RSA-SHA-256, ett publikt/privat nyckelpar) är de vanligaste. Payloaden innehåller anspråk som `sub` (ämne, vanligtvis ett användar-ID), `iat` (utfärdat-vid Unix-tidsstämpel), `exp` (utgångs-Unix-tidsstämpel), `aud` (avsedd målgrupp) och anpassade programanspråk som roller eller behörigheter. Base64url är inte kryptering: det är en URL-säker variant av Base64 som ersätter `+` med `-` och `/` med `_`, och utelämnar utfyllnad. Vem som helst som innehar råtokensträngen kan avkoda headern och payloaden utan signeringsnyckeln. Bara signatursegmentet kräver nyckeln för verifiering. Det är därför det är en säkerhetsrisk att klistra in en live-produktionstoken i en extern online-avkodare: om tokens `exp` fortfarande är i framtiden och tjänsten loggar indata kan sessionen den representerar äventyras.

Verktygen som används i den här guiden

Vanliga frågor

Skickas min token till någon server när jag avkodar den?

Nej. Avkodaren delar upp token, Base64Url-avkodar headern och payloaden och visar dem i minnet. Den valfria HMAC-kontrollen använder din webbläsares inbyggda Web Crypto API. Inget färdas över nätverket, vilket spelar roll eftersom en JWT ofta innehåller personuppgifter och en session som fortfarande är aktiv. Öppna din webbläsares nätverkspanel medan du avkodar så ser du att ingen begäran går ut.

Kan det här verktyget verifiera en RS256- eller ES256-signatur?

Inte fullt ut, och det kommer inte att låtsas göra det. HS256 använder en delad hemlighet för både signering och verifiering, så att klistra in den hemligheten låter verktyget bekräfta signaturen i din webbläsare. RS256 och ES256 använder en privat nyckel för att signera och en separat publik nyckel för att verifiera; verktyget läser och validerar dess claims och giltighetstid men avstår från att påstå en signatur det inte kan kontrollera. För de tokenerna, verifiera på tjänsten som har den publika nyckeln.

Källor