JWT: mi ez, a JSON Web Token felépítése és alkalmazása

Mi az a JWT?

JSON Web Token (JWT) — egy nyílt szabvány (RFC 7519), amely egy kompakt és önálló módot határoz meg az információk felek közötti továbbítására JSON-objektum formájában. A JWT-ben lévő információkat claims-nek nevezzük — állítások a szubjektumról (felhasználó) és további attribútumokról. Minden claim egy kulcs-érték pár: felhasználói azonosító, szerepkör, lejárati idő, kibocsátó.

A JWT-t azért nevezik önállónak, mert minden ellenőrzéshez szükséges információ magában a tokenben található. A szervernek nem kell adatbázishoz vagy külső tárhelyhez fordulnia a token érvényességének megállapításához — elég ellenőrizni az aláírást. Ez a tulajdonság teszi a JWT-t ideálissá elosztott rendszerekhez és mikroszolgáltatás-architektúrákhoz, ahol több szolgáltatásnak kell hitelesítenie kéréseket közös munkamenet-tároló nélkül.

A Auth0, 2025 adatai szerint a mobil- és webalkalmazások több mint 65%-a használja a JWT-t elsődleges tokenformátumként API-hitelesítéshez, megelőzve az átlátszatlan tokeneket és a munkamenet-azonosítókat.

A JWT felépítése: header, payload és signature

A JWT három, pontokkal elválasztott részből áll: header.payload.signature. Minden rész egy Base64url-kódolt JSON. Vizsgáljuk meg részletesen az egyes részeket.

Header — algoritmus és tokentípus

A Header két kötelező mezőt tartalmaz: alg (algorithm — aláírási algoritmus) és typ (type — tokentípus, mindig „JWT”). Az algoritmus lehet szimmetrikus (HS256 — HMAC SHA-256-tal) vagy aszimmetrikus (RS256 — RSA SHA-256-tal, ES256 — ECDSA P-256-tal). Az aszimmetrikus algoritmusok előnyösebbek, mert lehetővé teszik az ügyfél számára az aláírás ellenőrzését a titkos kulcs birtoklása nélkül.

Példa dekódolt header-re:

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

Payload — claims és adatok

A Payload claims-eket — állításokat tartalmaz a szubjektumról. A claims-ek három típusra oszthatók: regisztrált (iss, sub, aud, exp, nbf, iat, jti), nyilvános (a fejlesztő által az IANA Registry-ben meghatározott) és privát (a felek között egyeztetett). sub (subject) — a felhasználó egyedi azonosítója. exp (expiration) — a token lejárati ideje. iss (issuer) — a token kibocsátója.

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

Signature — integritás ellenőrzése

A Signature az aláírási algoritmus alkalmazásával jön létre a header és payload összefűzésére, titkos vagy privát kulcs használatával. Képlet: HMACSHA256(base64UrlEncode(header) + „.” + base64UrlEncode(payload), secret) HMAC esetén, vagy RSASHA256(...) aszimmetrikus algoritmus esetén. A fogadó ugyanúgy kiszámítja az aláírást és összehasonlítja a kapottal — ha egyeznek, az adatok nem változtak.

Hogyan működik a JWT: létrehozás és ellenőrzés

A működési folyamat két fázisból áll: a token létrehozása (kibocsátása) a hitelesítési szerver által, és a token ellenőrzése az ügyfél vagy az erőforrás-szerver által. A hitelesítési szerver megkapja a felhasználó hitelesítő adatait, létrehozza a payload-ot claims-ekkel, és aláírja. A kapott JWT elküldésre kerül az ügyfélnek a bejelentkezési kérelemre adott válaszban vagy az OAuth 2.0 / OpenID Connect válasz törzsében.

JWT a mobil hitelesítésben

A mobilalkalmazásokban a JWT a következőképpen használatos: sikeres bejelentkezés után a felhasználó egy access tokent kap JWT formátumban. Az alkalmazás biztonságos tárolóba menti (Keychain iOS-en, EncryptedSharedPreferences Androidon). Minden API-kérésnél az alkalmazás hozzáadja a Authorization: Bearer <token> fejlécet. Az API-szerver ellenőrzi a JWT aláírást, kinyeri a claims-eket, és ezek alapján hoz hozzáférési döntést — anélkül, hogy az adatbázishoz fordulna.

A Google Codelabs, 2025 adatai szerint a JWT használata a Firebase Authentication-ben 40–60%-kal csökkenti a hitelesítési szerverhez intézett kérések számát a munkamenet-tokenekhez képest, mivel az adatok helyileg, minden mikroszolgáltatáson ellenőrizhetők. Ez különösen fontos a nagy terhelésű architektúrákban, ahol minden ezredmásodperces késleltetés befolyásolja a felhasználói élményt. Perccenként 50 000 kérés esetén a JWT-re való áttérés akár 10, introspection-kéréseket feldolgozó szerverpéldányt is megtakaríthat.

JWT vs Session Token

A JWT és a Session Token ugyanazt a feladatot oldja meg — a kérések hitelesítését — de alapvetően különböznek az architektúrában. A Session Token egy véletlenszerű azonosító sztring, amely a szerveren tárolt munkamenet-adatokra hivatkozik (stateful). A JWT — egy önálló token, amely minden adatot magában hordoz (stateless).

A JWT előnyei és hátrányai

A JWT az elosztott rendszerekben nyer: a mikroszolgáltatások helyileg ellenőrizhetik a tokent megosztott tároló nélkül. Például egy öt mikroszolgáltatásból álló architektúrában minden szolgáltatás 1–2 ms alatt ellenőrzi a JWT-t hálózati hívás nélkül, míg a session token minden kérésnél központi Redis elérését igényli, 10–30 ms késleltetést adva hozzá. A JWT-t azonban nehéz visszavonni — ha a tokent már kibocsátották, a lejáratig érvényes. A Session Token könnyen visszavonható a rekord adatbázisból vagy Redis-ből való törlésével.

A mobilalkalmazások számára a kombinált megközelítés — rövid élettartamú (15–30 perces) JWT és Refresh Token — egyensúlyt teremt a teljesítmény és a biztonság között. A JWT az API-hoz való hozzáférésre szolgál, a refresh token (általában átlátszatlan) pedig új JWT-k beszerzésére. A JWT kompromittálása esetén a támadónak 15–30 percig van hozzáférése; a refresh token kompromittálása esetén a munkamenet rotációval és újrafelhasználás-észleléssel blokkolásra kerül.

JWT biztonság

A JWT biztonsága a helyes implementációtól függ. A leggyakoribb sebezhetőség az „alg none” támadás: a támadó a token header-jét „alg”: „none”-ra módosítja, és a szerver az algoritmus ellenőrzése nélkül elfogadja a hamis tokent. Védelem: mindig ellenőrizze, hogy a header-ben lévő algoritmus megfelel-e a vártnak (RS256, ES256), és utasítsa el a alg: none tokeneket.

Tipikus sebezhetőségek

A JWT sebezhetőségei magukban foglalják még: gyenge titkos kulcs HMAC esetén (perceken belül feltörhető), a privát kulcs kiszivárgása (bármilyen adat aláírása a szerver nevében), érzékeny adatok tárolása a payload-ban (a JWT nem titkosít, csak aláír), támadás JWK header injection segítségével (saját nyilvános kulcs beillesztése). Ellenőrzött könyvtárak használata — Nimbus JOSE + JWT, jjwt (io.jsonwebtoken), PyJWT — csökkenti e sebezhetőségek kihasználásának kockázatát.

További védelmi intézkedés — JWK Thumbprint (RFC 7638): a nyilvános kulcs hozzákapcsolása a tokenhez ujjlenyomat (thumbprint) segítségével a header-ben. Ha a szerver tárolja a várt thumbprint-et minden ügyfél számára, a JWK header injection támadás lehetetlenné válik — a szerver elutasít minden olyan kulcsot, amely nem egyezik a regisztrálttal. Az OAuth Security Workshop 2025 a JWK Thumbprint-et kötelező védelemként ajánlja minden, pénzügyi és orvosi alkalmazásokban használt JWT számára.

Kódpélda: JWT használata Kotlin-ban

A jjwt könyvtár (auth0/java-jwt) lehetővé teszi JWT-k létrehozását és ellenőrzését Android-alkalmazásban néhány sorban. Az alábbi példában a szerver sub és role paraméterekkel hoz létre tokent, az ügyfél pedig ellenőrzi az aláírást. A titkos kulcs biztonságos tárolásához a szerveren használjon környezeti változókat vagy HSM-et (Hardware Security Module) — a kulcs kódban vagy konfigurációs fájlban való tárolása súlyos biztonsági hiba.

JWT generálása

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))

// Token küldése az ügyfélnek
println("JWT: $token")

JWT ellenőrzése

fun verifyToken(token: String): Boolean {
    return try {
        val decoded = JWT.require(Algorithm.HMAC256(secret))
            .withIssuer("auth.example.com")
            .build()
            .verify(token)
        // Az aláírás érvényes, claims kinyerve
        println("Subject: ${decoded.subject}")
        true
    } catch (e: Exception) {
        println("Token invalid: ${e.message}")
        false
    }
}