Avkoda ett JWT och Inspektera Claims SäKert
Snabbt svar
En JWT är tre Base64URL-strängar sammanfogade med punkter: header.payload.signature. Avkoda header och payload med Base64URL-avkodning för att inspektera claims —men avkodning läser bara data, den verifierar inte äkthet. Verifiera alltid signature på servern. Använd vår JWT Decoder.
Introduktion
Ett JSON Web Token (JWT, RFC 7519) är ett kompakt, URL-säkert token-format använt för autentisering och auktorisering. Det har tre Base64URL-kodade delar separerade med punkter: header.payload.signature. Header beskriver algoritmen, payload bär claims (user id, roles, expiry) och signature bevisar att token utfärdats av en betrodd part. Avgörande: header och payload är kodade, inte krypterade —vem som helst kan läsa dem.
Steg för steg
-
Dela upp token i tre delar
En JWT ser ut som xxxxx.yyyyy.zzzzz. Dela på punkttecknet för att få rubriken (del 0), nyttolast (del 1) och signatur (del 2). Om det inte finns exakt tre delar är poletten felaktig.
-
Base64URL-avkoda rubriken
Rubriken är ett Base64URL-kodat JSON-objekt som {"alg":"HS256","typ":"JWT"}. Base64URL använder - och _ istället för + och / och utelämnar utfyllnad. Avkoda den och JSON.parse för att läsa algoritmen och skriv. Vår JWT-avkodare gör detta automatiskt.
-
Base64URL-avkoda nyttolasten (anspråk)
Nyttolasten är ett JSON föremål för anspråk. Registrerade anspråk inkluderar iss (emittent), sub (subjekt), aud (public), exp (expiration), nbf (icke-before), iat (emitted-at) och jti (token id). Privata anspråk är applikationsspecifika (t.ex. roll, e-post). Avkoda och inspektera, men lita inte på förrän det har verifierats.
-
Kontrollera giltighetstiden och not-before-anspråken
exp och nbf är Unix-tidsstämplar (sekunder). Om den aktuella tiden är över exp, har token gått ut och måste avvisas. Om den aktuella tiden är före nbf är token ännu inte giltig. Kontrollera dessa klientsida för UX, men tvinga dem på serversidan för säkerhet.
-
Verifiera signaturen på servern (aldrig på klientsidan)
Signaturen är HMAC-SHA256(hemlig, header.payload) för HS256, eller RSA/ECDSA signatur för RS256/ES256. Verifiering kräver den hemliga eller offentliga nyckeln, som aldrig får nå webbläsaren. Använd ett bibliotek som jsonwebtoken (Node) eller jose för att verifiera — skriv aldrig din egen krypto.
Exempel
En typisk JWT (tre delar)
Input: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpmeJf36POk6yJV_adQssw5c
Produktion: Header: {"alg":"HS256","typ":"JWT"} Payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}
Avkodad nyttolast med standardkrav
Input: Nyttolast av en riktig autentiseringstoken
Produktion: {"sub":"user-42","iss":"freeonlinetoolsgo.com","exp":1767229200,"iat":1767225600,"role":"admin"}
Upphört tokendetektering
Input: exp: 1609459200 (2021-01-01) kontrolleras på 2026-08-28
Produktion: Token is expired —current time (1767225600) > exp (1609459200). Reject and prompt re-login.
Vanliga problem
- Behandla avkodning som verifiering: vem som helst kan skapa en JWT med alla anspråk och en falsk signatur. Avkodning läser nyttolasten men bevisar ingenting. Verifiera alltid signaturen med den hemliga/offentliga nyckeln på servern innan du litar på anspråk.
- Genom att använda 'ingen'-algoritmen: JWT-specifikationen tillåter alg: ingen för osäkrade tokens. Om din verifierare accepterar alg: ingen, kan en angripare förfalska tokens. Konfigurera ditt bibliotek för att avvisa inga och vitlista förväntade algoritmer.
- Lagra JWTs i localStorage: XSS kan läsa localStorage och exfiltrera tokens. Föredrar httpOnly, Secure, SameSite=Strikta cookies för sessionstokens, eller kortlivade in-memory tokens med en refresh-token cookie.
- Kontrollerar inte exp/aud/iss: en stulen token är giltig tills den löper ut. Kontrollera alltid exp (utgång), aud (avsedd målgrupp) och utfärdare (utfärdare) på varje begäran för att förhindra uppspelning av token mellan tjänster.
Tips
- Använd kortlivade åtkomsttokens (15 minuter) plus långlivade uppdateringstoken – detta begränsar fönstret om en åtkomsttoken blir stulen.
- Föredra RS256 (asymmetrisk) framför HS256 (symmetrisk) när flera tjänster verifierar tokens: varje tjänst får den publika nyckeln, och endast utfärdaren har den privata nyckeln.
- Använd vår JWT-avkodare under utvecklingen för att inspektera vad servern utfärdar — den visar den avkodade rubriken, nyttolasten och en läsbar anspråkssammanfattning utan att skicka token någonstans.
- Lägg aldrig känsliga data (lösenord, PII) i en JWT nyttolast – den är Base64-kodad, inte krypterad, och alla som fångar upp token kan läsa varje anspråk.