Avkoda och inspektera JSON Web Tokens (JWT)

En JSON Web Token (JWT) är en kompakt och fristående standard för att säkert överföra information mellan parter som ett JSON-objekt. Informationen kan verifieras och litas på eftersom den är digitalt signerad. En JWT består av tre delar, separerade av punkter (.):

1. Huvud (Header): Den första delen specificerar typen av token, vilket är JWT, och vilken signeringsalgoritm som används, till exempel HS256 eller RS256. Detta JSON-objekt kodas sedan med Base64url för att bilda den första delen av JWT:n.

1. Nyttolast (Payload): Den andra delen innehåller anspråken (claims). Anspråk är påståenden om en entitet (vanligtvis en användare) och ytterligare data. Det finns standardiserade anspråk som iss (utfärdare), exp (förfallotid) och sub (ämne). Även nyttolasten är ett Base64url-kodat JSON-objekt.

1. Signatur (Signature): För att skapa signaturen tar man det kodade huvudet, den kodade nyttolasten, en hemlighet (secret), och signerar dem med den algoritm som specificerats i huvudet. Signaturen används för att verifiera att meddelandet inte har ändrats på vägen.

Eftersom huvudet och nyttolasten endast är kodade, inte krypterade, kan vem som helst läsa deras innehåll. En JWT-avkodare som denna gör just det: den tar en JWT-sträng, delar upp den och utför Base64url-avkodning på de två första delarna för att visa dig informationen i ett läsbart format. Den presenterar sedan de avkodade delarna som snyggt formaterad JSON, vilket kan vara till stor hjälp vid felsökning.

Nyttolasten i en JWT innehåller de så kallade anspråken (claims), vilka är nyckel/värde-par som beskriver en användare eller annan entitet. Dessa är centrala för att hantera autentisering och auktorisering. Man skiljer oftast på tre typer av anspråk: registrerade, publika och privata. De registrerade anspråken är en uppsättning fördefinierade anspråk som rekommenderas för att säkerställa interoperabilitet. Här är några av de vanligaste:

• iss (Issuer): Identifierar vem som har utfärdat token. Värdet är oftast en URL till utfärdaren.
• sub (Subject): Identifierar ämnet för token, det vill säga den användare eller enhet som tokenen handlar om. Detta är ofta ett unikt användar-ID.
• aud (Audience): Anger den eller de mottagare som tokenen är avsedd för. Om en mottagande tjänst inte finns med i aud-anspråket bör den avvisa tokenen.
• exp (Expiration Time): En numerisk tidsstämpel (Unix time) som anger när tokenen upphör att gälla. En JWT-avkodare översätter detta värde till ett mänskligt läsbart datum för att underlätta felsökning.
• nbf (Not Before): En tidsstämpel som anger den tidpunkt från vilken tokenen är giltig. Den bör inte accepteras före denna tid.
• iat (Issued At): En tidsstämpel som anger när tokenen utfärdades. Detta kan användas för att bestämma tokenens ålder.
• jti (JWT ID): Ett unikt ID för tokenen som kan användas för att förhindra att samma token återanvänds (replay attacks).

Det är avgörande att förstå skillnaden mellan att avkoda och att verifiera en JWT. Även om termerna ibland används felaktigt, representerar de två helt olika processer med olika säkerhetsimplikationer.

Avkodning är processen att läsa innehållet i en JWT. Huvudet och nyttolasten är kodade med Base64url, vilket är en reversibel process som inte kräver någon hemlig nyckel. Vem som helst med tillgång till en JWT kan avkoda dessa två delar och se informationen de innehåller, såsom användar-ID, roller och förfallotid. En JWT-avkodare som detta verktyg är designat för just detta ändamål: att snabbt och enkelt inspektera innehållet i en token för felsökning och utveckling. Det är som att öppna och läsa ett brev som inte är förseglat.

Verifiering är däremot en kritisk säkerhetsåtgärd. Det är processen att kontrollera signaturen för att säkerställa att tokenen är autentisk och att dess innehåll inte har manipulerats. För att verifiera en signatur behöver du den hemliga nyckeln (för symmetriska algoritmer som HS256) eller den publika nyckeln (för asymmetriska algoritmer som RS256) som motsvarar den privata nyckel som användes för att signera tokenen. Om signaturen är giltig kan du lita på innehållet. Om den är ogiltig har tokenen antingen manipulerats eller kommer från en opålitlig källa.

Detta verktyg utför endast avkodning. Du bör aldrig lita på data från en JWT i din applikation utan att först ha verifierat dess signatur.

När autentisering via JWT misslyckas kan det vara svårt att snabbt identifiera orsaken. En JWT-avkodare är ett ovärderligt verktyg för utvecklare för att diagnostisera vanliga problem genom att inspektera innehållet i en token. Här är några typiska scenarier där verktyget kan hjälpa:

1. Token har gått ut: Ett av de vanligaste felen är att en användares session plötsligt avslutas. Genom att klistra in deras JWT i avkodaren kan du omedelbart kontrollera exp-anspråket. Verktyget översätter Unix-tidsstämpeln till ett tydligt datum och klockslag, vilket bekräftar om tokenens giltighetstid har passerats.

1. Felaktig målgrupp (Audience): I en arkitektur med mikrotjänster kan ett API neka åtkomst för att tokenen var avsedd för en annan tjänst. Genom att avkoda tokenen kan du inspektera aud-anspråket och verifiera att det matchar den förväntade identifieraren för den anropade tjänsten.

1. Klockskillnader (Clock Skew): En token kan avvisas som ogiltig om det finns en tidsskillnad mellan servern som utfärdar tokenen och servern som validerar den. Genom att granska iat (Issued At) och nbf (Not Before) kan du identifiera om tokenen anses vara från framtiden eller för gammal på grund av osynkroniserade systemklockor.

1. Otillräckliga behörigheter: En användare kanske inte kan komma åt en specifik resurs trots en giltig session. Genom att avkoda tokenen kan du inspektera anpassade anspråk som roles eller permissions för att se exakt vilka behörigheter som har beviljats och om de är tillräckliga för den begärda åtgärden.

Är det säkert att klistra in en produktionstoken här? Ja. Detta verktyg är byggt med säkerhet i åtanke och körs helt och hållet i din webbläsare (klient-sida). Den JWT du klistrar in skickas aldrig över nätverket till våra eller några andra servrar. All avkodning sker lokalt på din dator, vilket gör det säkert att använda även med känsliga tokens från produktionsmiljöer.

Är avkodning av en JWT samma sak som att verifiera den? Nej, och detta är en mycket viktig distinktion. Avkodning innebär att man läser det Base64url-kodade innehållet i headern och nyttolasten. Verifiering är den kryptografiska processen där man kontrollerar signaturen för att säkerställa att tokenen är äkta och inte har ändrats. Detta verktyg avkodar endast och kan inte verifiera en token, eftersom det inte har tillgång till den hemliga nyckeln.

Hur kontrollerar jag när min token går ut? Klistra in hela JWT-strängen i inmatningsfältet. Verktyget avkodar automatiskt nyttolasten och visar alla dess anspråk. Leta efter exp-anspråket. Vår JWT-avkodare omvandlar automatiskt den numeriska Unix-tidsstämpeln till ett läsbart datum och klockslag, så att du direkt kan se när tokenen förfaller.

Varför misslyckas min token att avkodas? Den vanligaste orsaken är att token-strängen är felaktigt formaterad eller ofullständig. En giltig JWT måste bestå av tre delar (huvud.nyttolast.signatur) separerade av punkter. Se till att du har kopierat hela strängen utan extra tecken eller mellanslag. Varje del måste också vara en giltig Base64url-kodad sträng. Om någon del är korrupt eller saknas kommer avkodningen att misslyckas.