UltKit

JWT-avkodare

Klistra in en JSON Web Token och läs dess header och payload som formaterad JSON. Utgångs- och utfärdandetider visas som datum, och du ser om token är giltig just nu. Avkodningen sker helt i din webbläsare, vilket är viktigt när token är en aktiv inloggningsuppgift.

0 tecken · 0 ord · 0 rader

0 tecken · 0 ord · 0 rader

Körs helt i den här webbläsarfliken. Din text laddas aldrig upp eller sparas.

Registrerade claims

De sju claim-namn som definieras i RFC 7519 §4.1. Alla är valfria; tider anges i sekunder sedan 1970-01-01 UTC.

ClaimBetydelse
issUtfärdare: vem som skapade och signerade token
subSubjekt: användaren eller entiteten som token gäller
audMålgrupp: vem token är avsedd för
expUtgångstid: avvisa token efter detta ögonblick
nbfInte före: avvisa token före detta ögonblick
iatUtfärdad: när token skapades
jtiJWT-ID: unik identifierare, används för att förhindra återanvändning

Vanliga alg-värden

alg-värdeBetydelse
HS256HMAC med SHA-256; en delad hemlighet signerar och verifierar
RS256RSA PKCS#1 v1.5-signatur med SHA-256; privat nyckel signerar, publik nyckel verifierar
PS256RSA-PSS med SHA-256
ES256ECDSA på kurvan P-256 med SHA-256; korta signaturer
EdDSAEd25519- eller Ed448-signaturer
noneOsignerad token; servrar bör avvisa den

Så är en JSON Web Token uppbyggd

JWT definieras i RFC 7519 (maj 2015), som föreslår att det uttalas som det engelska ordet "jot". Den vanliga signerade formen består av tre Base64url-strängar som sätts ihop med punkter: header.payload.signature. Headern anger signeringsalgoritmen i alg, till exempel HS256 eller RS256, och ofta ett nyckel-ID i kid. Payloaden innehåller claims, alltså JSON-fält som sub (användaren), iss (utfärdaren), aud (den avsedda mottagaren) samt exp, nbf och iat, som är tidpunkter i sekunder sedan 1 januari 1970 UTC. Avkodaren omvandlar dessa tre till din lokala tid och till ISO 8601, och visar om token har gått ut, ännu inte är giltig eller befinner sig inom sitt giltighetsfönster.

Base64url är en kodning, inte kryptering, så alla som har en token kan läsa dess payload på exakt samma sätt som den här sidan gör. Lägg aldrig lösenord, kortnummer eller andra hemligheter i claims. En token med fem delar åtskilda av punkter är en JWE, alltså en krypterad token. Innehållet går inte att läsa utan nyckeln, och avkodaren talar om det. Ett inledande "Bearer " som kopierats från en Authorization-header tas bort automatiskt.

Varför signaturen inte verifieras här

Signaturen visar att headern och payloaden har skapats av någon som har nyckeln och att de inte har ändrats sedan dess. För att kontrollera den behövs nyckeln: den delade hemligheten för HMAC-algoritmer som HS256, eller utfärdarens publika nyckel för RS256, ES256 eller EdDSA. Att klistra in en hemlig signeringsnyckel från produktion på en webbsida är en dålig idé, och en avkodare som låtsas gå i god för en token utan nyckel skulle ge falsk trygghet. Därför visar det här verktyget signaturen men verifierar den inte. Se det du ser som ett påstående som token gör, inte som ett faktum.

Verifiering hör hemma på din server, med ett underhållet bibliotek där den förväntade algoritmen är låst. Två historiska misstag förklarar varför: att acceptera alg "none", vilket låter vem som helst förfalska en osignerad token, och algoritmförväxling, där en server som förväntar sig RS256 luras att kontrollera en HS256-signatur med den publika nyckeln som HMAC-hemlighet. En avkodare är till för felsökning: att se vilka claims en leverantör utfärdar, upptäcka fel audience eller förstå att en session misslyckades för att exp passerade för en minut sedan. Om du vill läsa Base64url-segmenten i råformat kan du använda Base64-avkodaren.

Vanliga frågor

Är det säkert att klistra in en riktig åtkomsttoken i en JWT-avkodare?
På den här sidan lämnar token aldrig din webbläsare. Ändå fungerar en giltig token som ett lösenord tills den går ut, så välj hellre utgångna eller testade token och håll skarpa token borta från skärmbilder och chattar.
Varför visas min token som utgången fast den precis utfärdades?
Kontrollera först klockan på din enhet. Vissa utfärdare ger åtkomsttoken en livslängd på bara några minuter, och en token som kopierats från en logg kan vara äldre än den ser ut. Ett exp som anges i millisekunder i stället för sekunder ger motsatt effekt och hamnar tusentals år fram i tiden.
Kan någon ändra payloaden i min JWT?
De kan ändra och koda om den, men signaturen stämmer då inte längre. En server som verifierar signaturer med rätt nyckel och algoritm avvisar den ändrade token.
Vad är skillnaden mellan JWS och JWE?
En JWS (RFC 7515) är signerad, har tre delar och kan läsas av vem som helst. En JWE (RFC 7516) är krypterad, har fem delar och bara den som har nyckeln kan läsa payloaden.
Blir en JWT ogiltig när man loggar ut?
Inte i sig själv. En signerad JWT förblir giltig till exp om inte servern för en spärrlista eller kontrollerar en sessionspost, vilket är varför åtkomsttoken oftast får korta livslängder.