JWT-avkodare

Vad en JWT-avkodare faktiskt gör

En JSON Web Token (JWT) ser ut som en lång, ogenomtränglig sträng av slumpmässiga tecken, men den är varken krypterad eller ett hemligt chiffer. Det är en kompakt, URL-säker behållare som bär strukturerad data mellan två parter. Klistra in en token i avkodaren ovan så delar den upp strängen och visar dig den riktiga JSON:en inuti — metadatan, anspråken (claims), vem token är avsedd för, och när den upphör att gälla. Allt sker direkt i din webbläsare. Token laddas aldrig upp, loggas aldrig och skickas aldrig någonstans, vilket spelar stor roll när det du undersöker är en aktiv sessionsuppgift.

Tre delar, två punkter

Varje välformad JWT är tre Base64url-kodade strängar sammanfogade med punkter: header.payload.signature. Det enda punkttecknet är hur parsers vet var en sektion slutar och nästa börjar, och det är varför en token med fel antal punkter avvisas innan något annat ens läses.

Headern är ett litet JSON-objekt som beskriver själva token. Den innehåller nästan alltid typ (typen, oftast JWT) och alg — signeringsalgoritmen, som HS256 (HMAC med SHA-256) eller RS256 (RSA med SHA-256). Headern talar om för en verifierare exakt hur signaturen togs fram.

Payloaden är den del de flesta bryr sig om. Det är ett annat JSON-objekt som håller claims (anspråken) — påståenden om användaren och token. Specifikationen sorterar claims i registrerade (standardiserade, reserverade namn), publika och privata (anpassade namn du själv uppfinner för din app). Att avkoda payloaden är det som avslöjar vem som är inloggad, vilken roll de har och när deras session löper ut.

Signaturen är den kryptografiska förseglingen. Den beräknas över den kodade headern och payloaden med hjälp av algoritmen från headern plus en hemlig eller privat nyckel. Eftersom den täcker båda de andra sektionerna gör varje ändring av headern eller payloaden — även ett enda tecken — den ogiltig.

De claims du oftast ser

De registrerade claims är korta, tre-bokstavsnamn definierade av RFC 7519 så att olika system kan samverka. En handfull dyker upp nästan överallt:

• iss — issuer (utfärdare): vem som skapade token (din auth-server eller identitetsleverantör).
• sub — subject (subjekt): huvudpersonen token handlar om, oftast ett stabilt användar-ID.
• aud — audience (mottagare): mottagaren token är avsedd för. Ett API bör avvisa tokens vars mottagare inte är det själv.
• exp — expiration time (utgångstid): en Unix-tidsstämpel efter vilken token inte får accepteras.
• iat — issued at (utfärdad): Unix-tidsstämpeln när token skapades.

Du kan även stöta på nbf (inte före) och jti (ett unikt token-ID). Tidsstämplar är sekunder sedan 1970 i UTC, vilket är varför en avkodare som visar dem som läsbara datum sparar dig det mentala räknearbetet med att kontrollera om en token redan gått ut.

Att avkoda är inte att verifiera — det här är delen som bits folk i baken

Den här distinktionen är den absolut viktigaste saken att förstå om JWT:er. Avkodning betyder att läsa innehållet: det kräver ingen nyckel och vem som helst som har token kan göra det, eftersom Base64url är en kodning, inte kryptering. Verifiering betyder att bevisa att token är äkta och oförvanskad — räkna om signaturen med rätt hemliga eller publika nyckel och bekräfta att den matchar.

Det här verktyget avkodar. Det visar vad token säger, inte om token är trovärdig. En token kan vara förfalskad, utgången eller återanvänd och ändå avkodas till helt ren JSON. Fatta aldrig ett auktoriseringsbeslut baserat enbart på avkodade claims. I produktion verifierar du signaturen på serversidan, kontrollerar exp, och bekräftar att iss och aud matchar det du förväntar dig — med hjälp av ett beprövat bibliotek, aldrig egenhändigt hopsatt strängjämförelse.

En payload är inget kassaskåp

Eftersom payloaden bara är Base64url-kodad kan den läsas av vem som helst som fångar upp token. Behandla allt i den som offentligt. Lägg inte lösenord, fullständiga kortnummer, hemliga nycklar eller annan känslig personlig data i JWT-claims — om du kan avkoda det här med ett klick kan vem som helst annan som får tag på en kopia göra samma sak. Signaturen skyddar mot ändring, aldrig mot läsning. Om du verkligen behöver dölja payload-innehåll är det ett jobb för JWE (krypterade tokens), en helt annan specifikation.

Integritet och relaterade verktyg

Att inspektera en token är en känslig handling, så den här avkodaren körs helt klientsidigt — parsningen är vanlig JavaScript i din flik och ingenting lämnar din dator. Att klistra in en sessionstoken i ett serverbaserat verktyg innebär att ge en aktiv inloggningsuppgift till en tredje part, vilket är exakt vad du bör undvika. För kodningen bakom det hela, se vårt Base64-verktyg, och utforska resten av våra utvecklarverktyg för fler verktyg som körs lokalt.

Vanliga frågor