JWT Decoder

Vad är en JWT?

En JSON Web Token (JWT, uttalas "jot") är ett kompakt, signerat JSON-objekt definierat i RFC 7519. Det bär claims mellan två parter, oftast mellan en auth-server och ett API. Servern utfärdar token efter lyckad autentisering, och klienten bifogar den till varje API-anrop via headern `Authorization: Bearer ...`.

JWTs består av tre base64url-kodade delar sammanfogade med punkter. De är inte krypterade, bara signerade. Den som har token kan läsa innehållet, varför lösenord och andra hemligheter aldrig får ligga i payloaden.

Fördelen jämfört med server-side sessioner: en JWT är self-contained. En API-server kan validera token och hämta rättigheter utan att kontakta auth-servern eller fråga ett session-store. Det skalar horisontellt utmärkt, men kostar möjligheten att återkalla enskilda tokens före utgång.

Header, payload, signature förklarade

Varje JWT har tre delar, sammanfogade med enskilda punkter:

• Header: litet JSON-objekt med `alg` (algoritm, t.ex. HS256, RS256, ES256) och `typ` (vanligtvis "JWT"). Ibland även `kid` (key ID) som ledtråd om vilken nyckel som användes för signering.
• Payload: JSON-objekt som håller claims. Standardfält är `iss` (issuer), `sub` (subject), `aud` (audience), `exp` (expiration), `nbf` (not before), `iat` (issued at) och `jti` (unikt token-ID). Egna fält tillåts vid sidan av.
• Signature: beräknad över `base64url(header) + "." + base64url(payload)` med konfigurerad algoritm. Den skyddar integriteten: utan nyckeln kan innehållet inte ändras obemärkt.

Viktigt: base64url är kodning, inte kryptering. Header och payload är läsbara för vem som helst som tittar.

JWT vs. sessionskakor

Båda metoderna bevarar ett autentiserat tillstånd, men på olika sätt:

• Sessionskaka: ogenomskinligt ID, servern slår upp det fullständiga tillståndet i session-store. Återkallning är omedelbar, men varje förfrågan kostar en uppslagning.
• JWT: bär själva tillståndet, säkrad endast av signatur. Ingen uppslagning behövs, perfekt för mikrotjänstarkitekturer, men återkallning före utgång kräver allow/deny-lista.
• Storlek: JWTs ligger ofta på 300 till 1500 byte. Session-ID:n är vanligen runt 32 byte. Vid många API-anrop summeras JWT-storleken i bandbredd.
• Lagring: kakor (HttpOnly, Secure, SameSite) är den säkrare lagringsplatsen för webbläsare. localStorage är exponerat för XSS.

Tumregel: håll dig till sessioner för rena server-appar, använd JWTs för API-gateways och mobila backends, helst med korta livstider och refresh-token-flöde.

JWT-säkerhet: vad göra åt `algorithm: none`?

JWTs har drabbats av flera spektakulära biblioteksbuggar de senaste åren. De största fallgroparna:

• `alg: none`: flera bibliotek brukade acceptera osignerade tokens när headern hävdade så. Lösning: tillåt aldrig `none`, hårdkoda den tillåtna algoritmen på servern.
• HS256/RS256-förvirring: en angripare signerar en token med RSA-publika nyckeln som HMAC-secret, servern validerar den som HS256 i stället för RS256, och luras. Försvar: tillåtet `alg` är fastlagt på servern.
• `kid` injection: fältet `kid` pekar på en nyckel, men osanerat kan det leda till path traversal eller SQL-injection. Behandla värdet som untrusted input.
• Svaga secrets: HS256-tokens med "secret" eller "password" som nyckel faller på sekunder genom brute force. Använd minst 256 slumpmässiga bitar, helst från `crypto.getRandomValues()` eller `/dev/urandom`.
• Lång livstid: varje utfärdad JWT är giltig till utgång, även efter att en användare har "loggat ut". Använd korta livstider (15 min) plus refresh-token-flöde, eller en deny-lista för känsliga endpoints.

OWASP-fusklappar och RFC 8725 (JWT Best Current Practices) är obligatorisk läsning.

Hur validerar jag en JWT?

En komplett validering täcker mycket mer än bara signaturen. Ordning i serverkoden:

• Tolka headern, kontrollera `alg` mot en allowlist (t.ex. endast RS256).
• Verifiera signaturen med nyckeln som matchar issuer-konfigurationen. Med JWKS, använd `kid` för uppslagning, men whitelista värdena först.
• Kontrollera standardclaims: `iss` matchar förväntad issuer, `aud` innehåller din egen audience, `exp` ligger i framtiden, `nbf` och `iat` ligger i det förflutna (tillåt liten clock-skew-tolerans).
• Validera dina egna claims (roller, tenant-ID, scopes) mot din affärsmodell.
• Om tidig återkallning krävs, kontrollera deny / logout-listan.

Förlita dig på ett etablerat bibliotek (jose, jjwt, jsonwebtoken etc.), inte på handskriven kod. Kryptografi är inget hobbyprojekt.

Hosta din auth-backend hos KernelHost

En JWT-utfärdare och resource-server behöver en pålitlig backend med låg latens. KernelHost driver egna VPS- och dedikerade servrar i Frankfurt FRA01 med DDoS-skydd, IPv4 + IPv6 och 1 Gbit/s uplink. Låg RTT till europeiska slutanvändare, rättvisa priser, ingen vendor lock-in. Företagssäte Wien (AT), datacenter Frankfurt (DE).

JWT FAQ