JWT-avkodare

En JSON Web Token ser ut som en oläslig klump av tecken, men i själva verket är det bara tre Base64URL-kodade delar sammanfogade med punkter: en header, en payload och en signatur. Att avkoda header och payload är inte kryptering över huvud taget — vem som helst med token kan läsa claims i den, vilket är exakt anledningen till att känslig data aldrig bör stoppas in i en JWT-payload. Problemet är att de tokens folk behöver undersöka sällan är engångsdata avsedd för test. Det handlar ofta om en aktiv sessionstoken från en produktionsapp, en API-åtkomsttoken, eller en inloggningscookie som hämtats direkt från webbläsarens utvecklarverktyg under felsökning — en verklig autentiseringsuppgift som, i fel händer, ger verklig åtkomst. Att klistra in den på en godtycklig webbplats lämnar över din session till en server du inte vet något om.

Det här verktyget gör aldrig så. Header och payload avkodas med ren JavaScript som körs i din webbläsare i samma stund du klistrar in en token — delas upp vid punkterna, Base64URL-avkodas och tolkas som JSON — och inget av det skickas någonstans. Signaturverifiering fungerar på samma sätt, med hjälp av Web Crypto API (`SubtleCrypto`) som finns inbyggt i alla moderna webbläsare: HMAC-algoritmer (HS256, HS384, HS512) verifieras mot en hemlighet du skriver in, och RSA-algoritmer (RS256, RS384, RS512) mot en publik nyckel du klistrar in i PEM-format. Både den kryptografiska hemligheten och själva verifieringen stannar lokalt i fliken; uppdatera sidan så är allt — token, hemlighet, nyckel — borta.

Klistra in en token för att se dess header och payload snyggt formaterade, tillsammans med en tolkning av standardclaimsen `exp`, `iat` och `nbf` omvandlade till läsbara datum, med en tydlig "Utgången"-märkning om tokenens `exp` redan har passerat — praktiskt för att bekräfta att en felrapport om "jag blev utloggad" faktiskt bara handlar om en utgången token. Ange matchande hemlighet eller publik nyckel för att kontrollera om signaturen är äkta eller har manipulerats. Algoritmer som verktyget inte kan verifiera, och den osignerade `none`, avkodas fortfarande utan problem, men verifiering erbjuds inte snarare än att simulera ett resultat. För lokal utveckling låter de redigerbara header/payload-fälten dig justera ett claim — säg, ändra ett användar-ID eller en roll — och signera om token med samma hemlighet som din testserver använder, vilket är ett vanligt sätt att testa auktoriseringslogik utan att behöva starta ett helt inloggningsflöde.

Eftersom en JWT:s payload är vanlig, läsbar JSON när den väl är avkodad, passar den naturligt ihop med verktyget JSON Formatter & Validator om du behöver granska ett djupt nästlat claim närmare. En säkerhetspåminnelse värd att upprepa: eftersom avkodning inte kräver någon hemlighet alls bör du behandla varje token som känslig så fort du är klar med att inspektera den, och rotera autentiseringsuppgifter som bara var tänkta att vara kortlivade om du inte är säker på var de klistrats in innan de hamnade här.