Dekódovat JSON Web Token (JWT)

Co je JWT (JSON Web Token)?

JSON Web Token, zkráceně JWT (vyslovuje se "jot"), je kompaktní formát definovaný RFC 7519, který umožňuje přenos série tvrzení (claims) mezi dvěma stranami. JWT, neboli JWT token, je dnes dominantní formát pro přenášení autentifikované identity v HTTP API. JWT se prezentuje jako ASCII řetězec složený ze tří segmentů oddělených tečkami:

header.payload.signature

Každý segment je kódován v Base64URL, variantě Base64 bez paddingu =, která nahrazuje + za - a / za _, aby mohl cirkulovat v URL nebo HTTP headeru bez dodatečného escapování.

Anatomie JWT

JSON web token je složen ze tří dobře odlišených částí, každá hraje přesnou roli v autentifikačním mechanismu:

1. Header

Header je JSON objekt, který popisuje, jak je token podepsán. Obsahuje minimálně:

• alg (algorithm): použitý podpisový algoritmus. Typické hodnoty: HS256, RS256, ES256, EdDSA.
• typ (type): typ tokenu, téměř vždy "JWT".
• kid (key ID): volitelný, identifikuje, který klíč má být použit pro verifikaci podpisu. Praktické v přítomnosti rotujícího parku klíčů (JWKS).

2. Payload

Payload obsahuje claims, tedy tvrzení, která vydavatel činí o uživateli nebo session. RFC 7519 definuje sedm standardních claims (registered claims):

• iss (issuer): kdo vydal token, například "https://accounts.google.com".
• sub (subject): komu token patří, v praxi identifikátor uživatele.
• aud (audience): komu je token určen. Zabraňuje, aby token vydaný pro API A byl přijat API B.
• exp (expiration time): Unix timestamp, po kterém token již není validní.
• nbf (not before): timestamp, před kterým token ještě není aktivní.
• iat (issued at): timestamp vydání tokenu.
• jti (JWT ID): unikátní identifikátor tokenu, používaný pro revokaci a prevenci replay útoků.

K těmto standardním claims se obvykle přidávají custom claims specifické pro aplikaci (roles, scope, tenant_id, email, permissions...).

3. Signature

Signature je kryptografický kondenzát spočítaný na base64url(header) + "." + base64url(payload) pomocí klíče. Ona je tím, co dokazuje, že nikdo nemodifikoval header ani payload od vydání. Nejběžnější algoritmy:

• HS256 / HS384 / HS512: symetrický HMAC-SHA podpis. Sdílený secret mezi vydavatelem a verifikátorem. Jednoduché, ale nevhodné jakmile je více než jeden konzument.
• RS256 / RS384 / RS512: asymetrický RSA podpis. Vydavatel podepisuje svým privátním klíčem, jakýkoli konzument verifikuje odpovídajícím veřejným klíčem. De facto standard pro OAuth2 a OpenID Connect.
• ES256 / ES384 / ES512: asymetrický ECDSA podpis. Stejné vlastnosti jako RS256, ale s mnohem kratšími klíči a podpisy.
• EdDSA (Ed25519): moderní asymetrický podpis, rychlý a kompaktní.

Ještě jednou: podpis chrání integritu, ne důvěrnost. Payload zůstává čitelný pro každého, kdo token vlastní.

Proč dekódovat JWT?

Operace jwt token decode odpovídá několika konkrétním potřebám developera nebo bezpečnostního inženýra:

• Debug autentifikace: vaše API vrací 401 nebo 403, chcete vidět, co se skutečně nachází v payloadu (sub, scope, roles, exp) místo hádání.
• Ověřit claims: potvrdit, že token obsahuje očekávané tvrzení (například tenant_id nebo permissions) před hledáním jinde v autorizačním řetězci.
• Číst expiraci: převést timestamp exp na lidské datum pro potvrzení, že token je skutečně expirovaný, nebo naopak že by měl být ještě validní.
• Bezpečnostní audit: ujistit se, že třetí služba neuniká citlivé informace v payloadu (emaily, interní identifikátory, osobní údaje).
• Formace a pochopení: konkrétně vidět, jak vypadá jsonwebtoken vycházející z OAuth providera (Google, Auth0, Keycloak, AWS Cognito) pro pochopení mechaniky bez ponoření do dokumentace.
• Prozkoumávání veřejných tokenů: inspektovat JWT nalezený v logu, v cookie nebo v zachytitelné OAuth výměně.

Decoder vs Verifier: kritické rozlišení

Obě operace se zdají blízké, ale nemají nic společného z hlediska bezpečnostních záruk:

• Dekódovat JWT znamená rozdělit řetězec na . a aplikovat Base64URL reverz na první dva segmenty. Je to jednoduché čtení, na dosah jakéhokoli třířádkového skriptu. Žádná verifikace podpisu se nedělá.
• Verifikovat JWT znamená přepočítat podpis z headeru, payloadu a klíče, pak porovnat výsledek s podpisem přítomným v tokenu. To garantuje, že token nebyl falsifikován.

Praktický závěr: dekódování neznamená důvěřovat. Pokud nebyl podpis verifikován správným klíčem, obsah payloadu může být zcela vymyšlený. Pro důvěrovací fázi použijte náš JWT Verifier.

Jak ho používat

1. Získejte JWT k inspekci, například z hlavičky Authorization: Bearer <jwt>, ze session cookie, z localStorage prohlížeče, nebo z aplikačního logu.
2. Vložte kompletní řetězec do vstupního pole. Tři segmenty musí zůstat oddělené tečkami.
3. Nástroj okamžitě zobrazí header dekódovaný ve formátovaném JSON, s algoritmem a typem.
4. Payload je pak dekódován a zobrazen. Zde vidíte všechny standardní a custom claims.
5. Nástroj také indikuje informaci o podpisu (deklarovaný algoritmus, délka), bez její verifikace.
6. Pro potvrzení, že token nebyl falsifikován, přepněte na náš JWT Verifier s očekávaným veřejným klíčem nebo secretem.

Veškeré dekódování se provádí ve vašem prohlížeči v JavaScriptu: váš token není nikdy odeslán na naše servery.

JWT a bezpečnost: pasti k vyhnutí

Pár zlatých pravidel pro dobré používání JWT v produkci:

• Vždy verifikujte podpis na straně serveru před udělením jakéhokoli práva. Náš JWT Verifier přesně ilustruje tuto operaci.
• Preferujte RS256 nebo ES256 před HS256 pro veřejná API. Asymetrický podpis se vyhne sdílení secretu mezi vydavatelem a každým konzumentem.
• Vždy respektujte claim exp. JWT bez expirace nebo s příliš vzdálenou expirací je časovaná bomba v případě úniku.
• Validujte iss a aud na straně serveru, pro zabránění přijetí legitimního tokenu vydaného pro jinou službu omylem.
• Odmítněte alg: "none" na straně verifikace. Je to klasická díra, která umožňuje útočníkovi vyrobit libovolný payload.
• Udržujte krátké doby životnosti (například 15 minut) a kombinujte s delším, ale na straně serveru revokovatelným refresh tokenem.

Příklad dekódovaného JWT tokenu

Zde je typický JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiSm9obiIsImlhdCI6MTUxNjIzOTAyMn0.jrU9j8LZcRK2_BZjqXjU7lEpJbkqmXfTQIu9vT45j-I

Po dekódování zde je jeho obsah:

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

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

// Signature (binární, kódovaný v Base64URL)
HMACSHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

Kde najít JWT ke zkopírování?

V praxi JWT k dešifrování (ve smyslu dekódování) nejčastěji pochází z jednoho z těchto míst:

• HTTP cookie: otevřete vývojářské nástroje (F12), záložka Application nebo Storage, pak Cookies. Najděte cookie s názvem access_token, jwt, session nebo podobně.
• localStorage / sessionStorage: stejný panel, sekce Local Storage. Mnoho SPA tam ukládá svůj token pod klíčem token nebo auth.
• Hlavička Authorization: záložka Network, vyberte API požadavek, přečtěte hlavičku Authorization: Bearer <jwt>. Zkopírujte pouze část za Bearer .
• Server logy: JWT se občas objeví v logu gateway nebo reverse proxy (vyhnout se v produkci, ale užitečné v debugu).

Často kladené otázky

Ukázka požadavku

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

Vstupní schéma

Koncové body

• GET https://cdrn.fr/api/v1/tools - vypíše všechny dostupné nástroje
• GET https://cdrn.fr/api/v1/tools/jwt-decoder - získá schéma tohoto nástroje
• POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute - spustí tento nástroj s JSON payloadem