JWT: co to je, struktura JSON Web Token a použití

Co je JWT?

JSON Web Token (JWT) — je otevřený standard (RFC 7519), který definuje kompaktní a soběstačný způsob přenosu informací mezi stranami ve formě JSON objektu. Informace v JWT se nazývají claims — tvrzení o subjektu (uživateli) a dalších atributech. Každý claim je pár klíč-hodnota: identifikátor uživatele, role, doba platnosti, vydavatel.

JWT se nazývá soběstačný, protože všechny informace potřebné pro ověření jsou obsaženy uvnitř samotného tokenu. Server nemusí přistupovat k databázi nebo externímu úložišti, aby se ujistil o platnosti tokenu — stačí zkontrolovat podpis. Tato vlastnost činí JWT ideálním pro distribuované systémy a mikroservisní architekturu, kde několik služeb musí autentizovat požadavky bez sdíleného úložiště relací.

Podle údajů Auth0, 2025 používá více než 65 % mobilních a webových aplikací JWT jako hlavní formát tokenu pro autentizaci API, čímž předčí opaque tokeny a identifikátory relací.

Struktura JWT: header, payload a signature

JWT se skládá ze tří částí oddělených tečkami: header.payload.signature. Každá část je Base64url zakódovaný JSON. Pojďme si každou část podrobně prohlédnout.

Header — algoritmus a typ tokenu

Header obsahuje dvě povinná pole: alg (algorithm — algoritmus podpisu) a typ (type — typ tokenu, vždy „JWT”). Algoritmus může být symetrický (HS256 — HMAC s SHA-256) nebo asymetrický (RS256 — RSA s SHA-256, ES256 — ECDSA s P-256). Asymetrické algoritmy jsou preferovány, protože umožňují klientovi ověřit podpis bez vlastnictví tajného klíče.

Příklad dekódovaného header:

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

Payload — claims a data

Payload obsahuje claims — tvrzení o subjektu. Claims se dělí na tři typy: registrované (iss, sub, aud, exp, nbf, iat, jti), veřejné (definované vývojářem v IANA Registry) a soukromé (dohodnuté mezi stranami). sub (subject) — jedinečný identifikátor uživatele. exp (expiration) — časové razítko vypršení tokenu. iss (issuer) — vydavatel tokenu.

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

Signature — ověření integrity

Signature se vytváří aplikací algoritmu podpisu na zřetězení header a payload pomocí tajného nebo soukromého klíče. Vzorec: HMACSHA256(base64UrlEncode(header) + „.” + base64UrlEncode(payload), secret) pro HMAC, nebo RSASHA256(...) pro asymetrický algoritmus. Příjemce vypočítá podpis stejným způsobem a porovná jej s přijatým — pokud se shodují, data nebyla změněna.

Jak funguje JWT: vytvoření a ověření

Proces fungování JWT se skládá ze dvou fází: vytvoření (vydání) tokenu autentizačním serverem a ověření tokenu klientem nebo serverem zdrojů. Autentizační server obdrží přihlašovací údaje uživatele, vytvoří payload s claims a podepíše jej. Výsledný JWT je odeslán klientovi v odpovědi na požadavek přihlášení nebo v těle odpovědi OAuth 2.0 / OpenID Connect.

JWT v mobilní autentizaci

V mobilních aplikacích se JWT používá následujícím způsobem: po úspěšném přihlášení uživatel obdrží access token ve formátu JWT. Aplikace jej uloží do zabezpečeného úložiště (Keychain na iOS, EncryptedSharedPreferences na Androidu). Při každém požadavku na API aplikace přidá hlavičku Authorization: Bearer <token>. Server API ověří podpis JWT, extrahuje claims a na jejich základě rozhodne o přístupu — bez přístupu k databázi.

Podle údajů Google Codelabs, 2025 snižuje použití JWT v Firebase Authentication počet požadavků na autentizační server o 40–60 % ve srovnání s relacemi tokenů, protože data jsou ověřována lokálně na každé mikroslužbě. To je zvláště důležité v architekturách s vysokým zatížením, kde každá milisekunda zpoždění ovlivňuje uživatelský zážitek. Při 50 000 požadavcích za minutu může přechod na JWT ušetřit až 10 serverových instancí zpracovávajících introspection požadavky.

JWT vs Session Token

JWT a Session Token řeší stejný úkol — autentizaci požadavků — ale zásadně se liší architekturou. Session Token je náhodný identifikační řetězec odkazující na data relace uložená na serveru (stateful). JWT — soběstačný token obsahující všechna data v sobě (stateless).

Výhody a nevýhody JWT

JWT vítězí v distribuovaných systémech: mikroslužby mohou ověřovat token lokálně bez sdíleného úložiště. Například v architektuře s pěti mikroslužbami každá služba ověří JWT za 1–2 ms bez síťového volání, zatímco session token vyžaduje přístup k centralizovanému Redis při každém požadavku, přidává 10–30 ms zpoždění. JWT je však obtížné odvolat — pokud byl token již vydán, je platný do vypršení. Session Token lze snadno odvolat smazáním záznamu z DB nebo Redis.

Pro mobilní aplikace poskytuje kombinovaný přístup — JWT s krátkou životností (15–30 minut) a Refresh Token — rovnováhu mezi výkonem a bezpečností. JWT se používá pro přístup k API a refresh token (obvykle opaque) pro získávání nových JWT. Při kompromitaci JWT má útočník přístup na 15–30 minut; při kompromitaci refresh tokenu je relace blokována pomocí rotace a detekce opětovného použití.

Bezpečnost JWT

Bezpečnost JWT závisí na správné implementaci. Nejběžnější zranitelností je útok „alg none”: útočník změní header tokenu na „alg”: „none” a server bez kontroly algoritmu přijme falešný token. Ochrana: vždy kontrolovat, že algoritmus v header odpovídá očekávanému (RS256, ES256), a odmítat tokeny s alg: none.

Typické zranitelnosti

Zranitelnosti JWT zahrnují také: slabý tajný klíč pro HMAC (prolomení během minut), únik soukromého klíče (podepisování libovolných dat jménem serveru), ukládání citlivých dat v payload (JWT nešifruje, pouze podepisuje), útok prostřednictvím JWK header injection (vložení vlastního veřejného klíče). Použití ověřených knihoven — Nimbus JOSE + JWT, jjwt (io.jsonwebtoken), PyJWT — snižuje riziko zneužití těchto zranitelností.

Dalším ochranným opatřením je JWK Thumbprint (RFC 7638): připojení veřejného klíče k tokenu pomocí otisku (thumbprint) v header. Pokud server ukládá očekávaný thumbprint pro každého klienta, útok JWK header injection je nemožný — server odmítne jakýkoli klíč, který neodpovídá registrovanému. OAuth Security Workshop 2025 doporučuje JWK Thumbprint jako povinnou ochranu pro všechny JWT používané ve finančních a lékařských aplikacích.

Příklad kódu: práce s JWT v Kotlin

Knihovna jjwt (auth0/java-jwt) umožňuje vytvářet a ověřovat JWT v Android aplikaci během několika řádků. V níže uvedeném příkladu server generuje token s sub a role a klient ověřuje podpis. Pro bezpečné uložení tajného klíče na serveru používejte proměnné prostředí nebo HSM (Hardware Security Module) — ukládání klíče v kódu nebo konfiguračním souboru je hrubá bezpečnostní chyba.

Generování 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))

// Odeslání tokenu klientovi
println("JWT: $token")

Ověření JWT

fun verifyToken(token: String): Boolean {
    return try {
        val decoded = JWT.require(Algorithm.HMAC256(secret))
            .withIssuer("auth.example.com")
            .build()
            .verify(token)
        // Podpis je platný, claims extrahovány
        println("Subject: ${decoded.subject}")
        true
    } catch (e: Exception) {
        println("Token invalid: ${e.message}")
        false
    }
}