Avkoda en JSON Web Token (JWT)

Vad är en JWT (JSON Web Token)?

En JSON Web Token, förkortad JWT (uttalas "jot"), är ett kompakt format definierat av RFC 7519 som gör det möjligt att transportera en serie påståenden (claims) mellan två parter. JWT, eller JWT-token, är idag det dominerande formatet för att bära en autentiserad identitet i ett HTTP-API. En JWT presenteras som en ASCII-sträng sammansatt av tre segment separerade med punkter:

header.payload.signature

Varje segment är kodat i Base64URL, en variant av Base64 utan padding = och som ersätter + med - och / med _ så att den kan cirkulera i en URL eller en HTTP-header utan ytterligare escape.

Anatomi av en JWT

En json web token består av tre tydligt åtskilda delar, var och en med en exakt roll i autentiseringsmekanismen:

1. Header

Headern är ett JSON-objekt som beskriver hur tokenen är signerad. Den innehåller minst:

• alg (algorithm): den signaturalgoritm som används. Typiska värden: HS256, RS256, ES256, EdDSA.
• typ (type): tokenens typ, nästan alltid "JWT".
• kid (key ID): valfri, identifierar vilken nyckel som ska användas för att verifiera signaturen. Praktisk i närvaro av en uppsättning roterande nycklar (JWKS).

2. Payload

Payloaden innehåller claims, det vill säga de påståenden som utfärdaren gör om användaren eller sessionen. RFC 7519 definierar sju standard-claims (registered claims):

• iss (issuer): vem som utfärdat tokenen, till exempel "https://accounts.google.com".
• sub (subject): vem tokenen tillhör, i praktiken användaridentifieraren.
• aud (audience): vem tokenen är avsedd för. Undviker att en token utfärdad för API A accepteras av API B.
• exp (expiration time): Unix-timestamp efter vilken tokenen inte längre är giltig.
• nbf (not before): timestamp före vilken tokenen ännu inte är aktiv.
• iat (issued at): timestamp för utfärdande av tokenen.
• jti (JWT ID): tokenens unika identifierare, används för revokering och för att förhindra replay.

Till dessa standard-claims läggs i allmänhet anpassade claims specifika för applikationen (roles, scope, tenant_id, email, permissions...).

3. Signatur

Signaturen är ett kryptografiskt kondensat beräknat på base64url(header) + "." + base64url(payload) med hjälp av en nyckel. Det är den som bevisar att ingen har ändrat headern eller payloaden sedan utfärdandet. De vanligaste algoritmerna:

• HS256 / HS384 / HS512: symmetrisk HMAC-SHA-signatur. En hemlig nyckel delad mellan utfärdare och verifierare. Enkelt, men olämpligt så snart det finns mer än en konsument.
• RS256 / RS384 / RS512: asymmetrisk RSA-signatur. Utfärdaren signerar med sin privata nyckel, vilken konsument som helst verifierar med motsvarande publika nyckel. De facto-standard för OAuth2 och OpenID Connect.
• ES256 / ES384 / ES512: asymmetrisk ECDSA-signatur. Samma egenskaper som RS256 men med mycket kortare nycklar och signaturer.
• EdDSA (Ed25519): modern asymmetrisk signatur, snabb och kompakt.

Återigen: signaturen skyddar integriteten, inte konfidentialiteten. Payloaden förblir läsbar för var och en som har tokenen.

Varför avkoda en JWT?

Operationen jwt token decode svarar på flera konkreta behov för en utvecklare eller säkerhetsingenjör:

• Autentiseringsdebug: ditt API returnerar en 401 eller en 403, du vill se vad som faktiskt finns i payloaden (sub, scope, roles, exp) snarare än att gissa.
• Verifiera claims: bekräfta att en token verkligen innehåller det förväntade påståendet (till exempel tenant_id eller permissions) innan du letar på andra ställen i auktoriseringskedjan.
• Läsa utgången: konvertera timestamp exp till mänskligt datum för att bekräfta att en token verkligen är utgången, eller tvärtom borde fortfarande vara giltig.
• Säkerhetsgranskning: säkerställa att en tredjepartstjänst inte läcker känslig information i payloaden (e-postadresser, interna ID:n, personuppgifter).
• Utbildning och förståelse: konkret se hur en jsonwebtoken från en OAuth-leverantör (Google, Auth0, Keycloak, AWS Cognito) ser ut för att förstå mekaniken utan att dyka ner i dokumentationen.
• Utforskning av publika tokens: inspektera en JWT som hittats i loggar, i ett cookie eller i ett OAuth-utbyte som kan avlyssnas.

Decoder vs Verifier: den kritiska distinktionen

De två operationerna verkar närliggande men har inget med varandra att göra när det gäller säkerhetsgarantier:

• Avkoda en JWT består i att dela upp strängen på . och tillämpa omvänd Base64URL på de två första segmenten. Det är en enkel läsning, inom räckhåll för vilket trerads-skript som helst. Ingen signaturverifiering görs.
• Verifiera en JWT består i att räkna om signaturen utifrån headern, payloaden och en nyckel, och sedan jämföra resultatet med signaturen i tokenen. Det är det som garanterar att tokenen inte har förfalskats.

Praktisk slutsats: avkoda är inte att lita på. Så länge signaturen inte har verifierats med rätt nyckel kan innehållet i payloaden vara helt påhittat. För tillitsfasen, använd vår JWT Verifier.

Så använder du det

1. Hämta den JWT du vill inspektera, till exempel från en header Authorization: Bearer <jwt>, från en sessionscookie, från localStorage i webbläsaren, eller från en applikationslogg.
2. Klistra in hela strängen i inmatningsfältet. De tre segmenten ska förbli separerade med punkter.
3. Verktyget visar omedelbart den avkodade headern som formaterad JSON, med algoritm och typ.
4. Payloaden avkodas sedan och visas. Där ser du alla standard- och custom- claims.
5. Verktyget visar också signaturinformation (deklarerad algoritm, längd), utan att verifiera den.
6. För att bekräfta att tokenen inte har förfalskats, växla över till vår JWT Verifier med den förväntade publika nyckeln eller hemligheten.

All avkodning utförs i din webbläsare i JavaScript: din token skickas aldrig till våra servrar.

JWT och säkerhet: fallgropar att undvika

Några gyllene regler för att använda JWT korrekt i produktion:

• Verifiera alltid signaturen på serversidan innan du ger någon rättighet. Vår JWT Verifier illustrerar precis den operationen.
• Föredra RS256 eller ES256 framför HS256 för publika API:er. Asymmetrisk signatur undviker att dela en hemlighet mellan utfärdaren och varje konsument.
• Respektera alltid claimet exp. En JWT utan utgång eller med för långt utgångsdatum är en tidsinställd bomb vid läcka.
• Validera iss och aud på serversidan, för att undvika att en legitim token utfärdad för en annan tjänst accepteras av misstag.
• Avvisa alg: "none" vid verifiering. Det är en klassisk sårbarhet som tillåter en angripare att smida vilken payload som helst.
• Håll livstider korta (15 minuter till exempel) och kombinera med en refresh token som är längre men revokerbar på serversidan.

Exempel på avkodad JWT-token

Här är en typisk JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiSm9obiIsImlhdCI6MTUxNjIzOTAyMn0.jrU9j8LZcRK2_BZjqXjU7lEpJbkqmXfTQIu9vT45j-I

När den är avkodad är dess innehåll:

// Header
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload
{
  "sub": "123",
  "name": "John",
  "iat": 1516239022
}

// Signature (binaire, encodé en Base64URL)
HMACSHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

Var hittar man en JWT att kopiera?

I praktiken kommer en JWT att dekryptera (i betydelsen avkoda) oftast från en av dessa platser:

• HTTP-cookie: öppna utvecklarverktygen (F12), fliken Application eller Storage, sedan Cookies. Leta efter en cookie med namn access_token, jwt, session eller liknande.
• localStorage / sessionStorage: samma panel, sektion Local Storage. Många SPA:er lagrar sin token under en nyckel token eller auth.
• Headern Authorization: fliken Network, välj en API-förfrågan, läs headern Authorization: Bearer <jwt>. Kopiera endast delen efter Bearer .
• Serverloggar: en JWT förekommer ibland i loggar från en gateway eller en reverse proxy (att undvika i produktion, men användbart vid debug).

Vanliga frågor

Exempelförfrågan

curl -X POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute \
  -H "Content-Type: application/json" \
  -d '{"token":"..."}'

Indatasschema

Slutpunkter

• GET https://cdrn.fr/api/v1/tools - listar alla tillgängliga verktyg
• GET https://cdrn.fr/api/v1/tools/jwt-decoder - hämtar schemat för detta verktyg
• POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute - kör detta verktyg med en JSON-payload