JWT: vad är det, struktur för JSON Web Token och tillämpning

Vad är JWT?

JSON Web Token (JWT) — är en öppen standard (RFC 7519) som definierar ett kompakt och självförsörjande sätt att överföra information mellan parter i form av ett JSON-objekt. Information i JWT kallas claims — påståenden om subjektet (användaren) och ytterligare attribut. Varje claim är ett nyckel-värdepar: användar-ID, roll, utgångstid, utfärdare.

JWT kallas självförsörjande eftersom all information som behövs för verifiering finns inuti själva token. Servern behöver inte ansluta till en databas eller extern lagring för att säkerställa tokenens giltighet — det räcker att verifiera signaturen. Denna egenskap gör JWT idealisk för distribuerade system och mikrotjänstarkitektur, där flera tjänster måste autentisera förfrågningar utan gemensam sessionslagring.

Enligt data från Auth0, 2025 använder över 65 % av mobila och webbapplikationer JWT som primärt tokenformat för API-autentisering, vilket överträffar opaque-token och sessionsidentifierare.

Struktur för JWT: header, payload och signature

JWT består av tre delar separerade med punkter: header.payload.signature. Varje del är en Base64url-kodad JSON. Låt oss undersöka varje del i detalj.

Header — algoritm och tokentyp

Header innehåller två obligatoriska fält: alg (algorithm — signaturalgoritm) och typ (type — tokentyp, alltid “JWT”). Algoritmen kan vara symmetrisk (HS256 — HMAC med SHA-256) eller asymmetrisk (RS256 — RSA med SHA-256, ES256 — ECDSA med P-256). Asymmetriska algoritmer är att föredra eftersom de tillåter klienten att verifiera signaturen utan att inneha den hemliga nyckeln.

Exempel på avkodad header:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-id-1"
}

Payload — claims och data

Payload innehåller claims — påståenden om subjektet. Claims delas in i tre typer: registrerade (iss, sub, aud, exp, nbf, iat, jti), offentliga (definierade av utvecklaren i IANA Registry) och privata (överenskomna mellan parter). sub (subject) — unikt användar-ID. exp (expiration) — tidsstämpel för tokenutgång. iss (issuer) — tokenutfärdare.

{
  "sub": "user-abc-123",
  "iss": "https://auth.example.com",
  "aud": "my-mobile-app",
  "exp": 1812345678,
  "iat": 1812342078,
  "role": "premium_user"
}

Signature — integritetskontroll

Signature skapas genom att tillämpa signaturalgoritmen på sammanfogningen av header och payload med en hemlig eller privat nyckel. Formel: HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret) för HMAC, eller RSASHA256(...) för asymmetrisk algoritm. Mottagaren beräknar signaturen på samma sätt och jämför den med den mottagna — om de matchar har data inte ändrats.

Hur JWT fungerar: skapande och verifiering

Processen för JWT består av två faser: skapande (utfärdande) av token av autentiseringsservern och verifiering av token av klienten eller resursservern. Autentiseringsservern tar emot användarens autentiseringsuppgifter, skapar en payload med claims och signerar den. Den resulterande JWT skickas till klienten som svar på inloggningsförfrågan eller i svarskroppen för OAuth 2.0 / OpenID Connect.

JWT i mobil autentisering

I mobila applikationer används JWT på följande sätt: efter framgångsrik inloggning får användaren en access token i JWT-format. Applikationen lagrar den i säker lagring (Keychain på iOS, EncryptedSharedPreferences på Android). Vid varje API-anrop lägger applikationen till headern Authorization: Bearer <token>. API-servern verifierar JWT-signaturen, extraherar claims och fattar ett åtkomstbeslut baserat på dem — utan att ansluta till databasen.

Enligt data från Google Codelabs, 2025 minskar användningen av JWT i Firebase Authentication antalet förfrågningar till autentiseringsservern med 40–60 % jämfört med sessionstoken, eftersom data verifieras lokalt på varje mikrotjänst. Detta är särskilt viktigt i arkitekturer med hög belastning, där varje millisekunds fördröjning påverkar användarupplevelsen. Vid 50 000 förfrågningar per minut kan övergången till JWT spara upp till 10 serverinstanser som bearbetar introspection-förfrågningar.

JWT vs Session Token

JWT och Session Token löser samma uppgift — autentisering av förfrågningar — men skiljer sig fundamentalt i arkitektur. Session Token är en slumpmässig identifieringssträng som refererar till sessionsdata lagrad på servern (stateful). JWT — en självförsörjande token som innehåller all data i sig (stateless).

Fördelar och nackdelar med JWT

JWT vinner i distribuerade system: mikrotjänster kan verifiera token lokalt utan delad lagring. Till exempel, i en arkitektur med fem mikrotjänster verifierar varje tjänst JWT på 1–2 ms utan nätverksanrop, medan session token kräver åtkomst till en centraliserad Redis vid varje förfrågan, vilket lägger till 10–30 ms fördröjning. JWT är dock svårt att återkalla — om token redan har utfärdats är den giltig till utgången. Session Token kan enkelt återkallas genom att radera posten från DB eller Redis.

För mobila applikationer ger en kombinerad metod — JWT med kort livslängd (15–30 minuter) och Refresh Token — en balans mellan prestanda och säkerhet. JWT används för API-åtkomst, och refresh token (vanligtvis opaque) för att hämta nya JWT. Vid kompromettering av JWT har angriparen tillgång i 15–30 minuter; vid kompromettering av refresh token blockeras sessionen genom rotation och återanvändningsdetektering.

JWT-säkerhet

Säkerheten för JWT beror på korrekt implementering. Den vanligaste sårbarheten är “alg none”-attacken: angriparen ändrar token-headern till “alg”: “none” och servern accepterar den falska token utan att kontrollera algoritmen. Skydd: kontrollera alltid att algoritmen i headern matchar den förväntade (RS256, ES256) och avvisa tokens med alg: none.

Typiska sårbarheter

Sårbarheter i JWT inkluderar även: svag hemlig nyckel för HMAC (knäcks inom minuter), läckage av privat nyckel (signering av godtycklig data på serverns vägnar), lagring av känsliga data i payload (JWT krypterar inte, endast signerar), attack via JWK header-injektion (infoga egen publik nyckel). Användning av verifierade bibliotek — Nimbus JOSE + JWT, jjwt (io.jsonwebtoken), PyJWT — minskar risken för exploatering av dessa sårbarheter.

En ytterligare skyddsåtgärd — JWK Thumbprint (RFC 7638): koppling av den publika nyckeln till token via ett fingeravtryck (thumbprint) i headern. Om servern lagrar det förväntade thumbprintet för varje klient blir JWK header-injektion omöjlig — servern avvisar varje nyckel som inte matchar den registrerade. OAuth Security Workshop 2025 rekommenderar JWK Thumbprint som obligatoriskt skydd för alla JWT som används i finansiella och medicinska applikationer.

Kodexempel: arbeta med JWT i Kotlin

Biblioteket jjwt (auth0/java-jwt) gör det möjligt att skapa och verifiera JWT i en Android-applikation på några rader. I exemplet nedan genererar servern en token med sub och role, och klienten verifierar signaturen. För säker lagring av den hemliga nyckeln på servern, använd miljövariabler eller HSM (Hardware Security Module) — lagring av nyckeln i kod eller konfigurationsfil är ett grovt säkerhetsfel.

Generera JWT

val secret = "my-256-bit-secret-key-here"
val token = JWT.create()
    .withSubject("user-abc-123")
    .withIssuer("auth.example.com")
    .withClaim("role", "premium_user")
    .withExpiresAt(Date(System.currentTimeMillis() + 3600000))
    .sign(Algorithm.HMAC256(secret))

// Skicka token till klienten
println("JWT: $token")

Verifiera JWT

fun verifyToken(token: String): Boolean {
    return try {
        val decoded = JWT.require(Algorithm.HMAC256(secret))
            .withIssuer("auth.example.com")
            .build()
            .verify(token)
        // Signaturen är giltig, claims extraherade
        println("Subject: ${decoded.subject}")
        true
    } catch (e: Exception) {
        println("Token invalid: ${e.message}")
        false
    }
}