Dekódovať JSON Web Token (JWT)

Čo je JWT (JSON Web Token)?

JSON Web Token, skrátene JWT (vyslovované "jot"), je kompaktný formát definovaný RFC 7519, ktorý umožňuje prenášať sériu nárokov (claims) medzi dvomi stranami. JWT alebo JWT token je dnes dominantný formát na prenos autentifikovanej identity v HTTP API. JWT sa prezentuje ako ASCII reťazec zložený z troch segmentov oddelených bodkami:

header.payload.signature

Každý segment je kódovaný v Base64URL, variante Base64 bez paddingu =, ktorá nahrádza + za - a / za _, aby mohol cirkulovať v URL alebo HTTP hlavičke bez dodatočného escapovania.

Anatómia JWT

JSON web token je zložený z troch dobre odlišných častí, každá hrá presnú rolu v autentifikačnom mechanizme:

1. Header

Header je JSON objekt opisujúci, ako je token podpísaný. Obsahuje minimálne:

• alg (algorithm): použitý podpisový algoritmus. Typické hodnoty: HS256, RS256, ES256, EdDSA.
• typ (type): typ tokena, takmer vždy "JWT".
• kid (key ID): voliteľný, identifikuje, ktorý kľúč má byť použitý na overenie podpisu. Praktické v prítomnosti parku rotujúcich kľúčov (JWKS).

2. Payload

Payload obsahuje claims, čiže nároky, ktoré vydavateľ robí ohľadom užívateľa alebo session. RFC 7519 definuje sedem štandardných claims (registered claims):

• iss (issuer): kto vydal token, napríklad "https://accounts.google.com".
• sub (subject): komu patrí token, v praxi identifikátor užívateľa.
• aud (audience): pre koho je token určený. Zabraňuje, aby token vydaný pre API A bol akceptovaný API B.
• exp (expiration time): Unix timestamp, po ktorom token už nie je validný.
• nbf (not before): timestamp, pred ktorým ešte token nie je aktívny.
• iat (issued at): timestamp vydania tokena.
• jti (JWT ID): unikátny identifikátor tokena, používaný pre revokáciu a prevenciu replay útokov.

K týmto štandardným claims sa zvyčajne pridávajú custom claims vlastné aplikácii (roles, scope, tenant_id, email, permissions...).

3. Signature

Signature je kryptografický kondenzát počítaný na base64url(header) + "." + base64url(payload) pomocou kľúča. Je to ona, čo dokazuje, že nikto nemodifikoval header ani payload od vydania. Najbežnejšie algoritmy:

• HS256 / HS384 / HS512: symetrický HMAC-SHA podpis. Tajný kľúč zdieľaný medzi vydavateľom a verifikátorom. Jednoduché, ale nevhodné, akonáhle je viac ako jeden konzument.
• RS256 / RS384 / RS512: asymetrický RSA podpis. Vydavateľ podpisuje svojím privátnym kľúčom, akýkoľvek konzument overuje zodpovedajúcim verejným kľúčom. De facto štandard pre OAuth2 a OpenID Connect.
• ES256 / ES384 / ES512: asymetrický ECDSA podpis. Rovnaké vlastnosti ako RS256, ale s oveľa kratšími kľúčmi a podpismi.
• EdDSA (Ed25519): moderný asymetrický podpis, rýchly a kompaktný.

Znovu: podpis chráni integritu, nie dôvernosť. Payload zostáva čitateľný pre každého, kto má token.

Prečo dekódovať JWT?

Operácia jwt token decode odpovedá na viaceré konkrétne potreby vývojára alebo bezpečnostného inžiniera:

• Autentifikačný debug: vaše API vracia 401 alebo 403, chcete vidieť, čo sa skutočne nachádza v payloade (sub, scope, roles, exp) namiesto hádania.
• Overenie claims: potvrdiť, že token skutočne obsahuje očakávaný nárok (napríklad tenant_id alebo permissions) pred hľadaním inde v autorizačnom reťazci.
• Prečítanie expirácie: konvertovať exp timestamp na ľudský dátum pre potvrdenie, že je token skutočne expirovaný, alebo naopak že by mal byť ešte validný.
• Bezpečnostný audit: ubezpečiť sa, že tretia služba neuniká citlivé informácie v payloade (emaily, interné identifikátory, osobné údaje).
• Vzdelávanie a porozumenie: konkrétne vidieť, ako vyzerá jsonwebtoken vychádzajúci z OAuth providera (Google, Auth0, Keycloak, AWS Cognito) pre pochopenie mechaniky bez ponárania sa do dokumentácie.
• Prieskum verejných tokenov: inšpektovať JWT nájdené v logoch, v cookie alebo v interceptable OAuth výmene.

Decoder vs Verifier: kritický rozdiel

Dve operácie sa zdajú blízke, ale nemajú nič spoločné z hľadiska bezpečnostných záruk:

• Dekódovať JWT spočíva v rozdelení reťazca na . a aplikovaní inverzného Base64URL na prvé dva segmenty. Je to jednoduché čítanie, v dosahu akéhokoľvek trojriadkového skriptu. Žiadne overenie podpisu sa nerobí.
• Overiť JWT spočíva v prepočítaní podpisu z headera, payloadu a kľúča, potom porovnaní výsledku s podpisom prítomným v tokene. Je to to, čo garantuje, že token nebol falšovaný.

Praktický záver: dekódovať nerovná sa dôverovať. Pokiaľ nebol podpis overený so správnym kľúčom, obsah payloadu môže byť úplne falošný. Pre fázu dôvery použite náš JWT Verifier.

Ako ho používať

1. Získajte JWT na inšpekciu, napríklad z hlavičky Authorization: Bearer <jwt>, z session cookie, z localStorage prehliadača alebo z aplikačného logu.
2. Vložte kompletný reťazec do vstupného poľa. Tri segmenty musia zostať oddelené bodkami.
3. Nástroj okamžite zobrazí header dekódovaný vo formátovanom JSON, s algoritmom a typom.
4. Payload je potom dekódovaný a zobrazený. Vidíte v ňom všetky štandardné a custom claims.
5. Nástroj tiež indikuje informáciu o podpise (deklarovaný algoritmus, dĺžka), bez jeho overovania.
6. Pre potvrdenie, že token nebol falšovaný, prepnite na náš JWT Verifier s očakávaným verejným kľúčom alebo secretom.

Všetko dekódovanie sa vykonáva vo vašom prehliadači v JavaScripte: váš token nie je nikdy odoslaný na naše servery.

JWT a bezpečnosť: pasti, ktorým sa vyhnúť

Niekoľko zlatých pravidiel pre dobré používanie JWT v produkcii:

• Vždy overovať podpis na strane servera pred udelením akéhokoľvek práva. Náš JWT Verifier presne ilustruje túto operáciu.
• Preferovať RS256 alebo ES256 pred HS256 pre verejné API. Asymetrický podpis sa vyhýba zdieľaniu secretu medzi vydavateľom a každým konzumentom.
• Vždy rešpektovať claim exp. JWT bez expirácie alebo s príliš vzdialenou expiráciou je časovaná bomba v prípade úniku.
• Validovať iss a aud na strane servera, aby sa zabránilo akceptovaniu legitímneho tokena vydaného pre iný servis omylom.
• Odmietnuť alg: "none" na strane overovania. Je to klasická trhlina, ktorá umožňuje útočníkovi vyfalšovať akýkoľvek payload.
• Udržiavať krátke životnosti (15 minút napríklad) a spárovať s dlhším, ale serverovo revokovateľným refresh tokenom.

Príklad dekódovaného JWT tokena

Tu je typický JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiSm9obiIsImlhdCI6MTUxNjIzOTAyMn0.jrU9j8LZcRK2_BZjqXjU7lEpJbkqmXfTQIu9vT45j-I

Po dekódovaní tu je jeho obsah:

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

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

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

Kde nájsť JWT na kopírovanie?

V praxi JWT na dešifrovanie (v zmysle dekódovať) pochádza najčastejšie z jedného z týchto umiestnení:

• HTTP cookie: otvorte vývojové nástroje (F12), záložka Application alebo Storage, potom Cookies. Nájdite cookie nazvaný access_token, jwt, session alebo podobne.
• localStorage / sessionStorage: rovnaký panel, sekcia Local Storage. Mnoho SPA tam ukladá svoj token pod kľúčom token alebo auth.
• Authorization hlavička: záložka Network, vybrať API požiadavku, prečítať hlavičku Authorization: Bearer <jwt>. Skopírovať iba časť po Bearer .
• Server logy: JWT sa niekedy objavuje v logoch gateway alebo reverse proxy (vyhnúť sa v produkcii, ale užitočné v debugovaní).

Často kladené otázky

Ukážka požiadavky

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šetky dostupné nástroje
• GET https://cdrn.fr/api/v1/tools/jwt-decoder - získa schému tohto nástroja
• POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute - spustí tento nástroj s JSON payloadom