JSON Web Token (JWT): čo to je a ako funguje

Čo je JWT a na čo slúži

JSON Web Token (JWT) je štandard (RFC 7519) na reprezentáciu nárokov (claims) medzi dvoma stranami vo forme bezpečne podpísaného (a prípadne zašifrovaného) JSON objektu. Najčastejšie sa používa v systémoch autentifikácie a autorizácie ako spôsob, ako uchovať a prenášať informácie o používateľovi alebo oprávneniach bez potreby udržiavať stav na serveri (stateless).

Základná štruktúra

JWT je textový reťazec tvorený tromi časťami oddelenými bodkami:

header.payload.signature

• header (hlavička): JSON, ktorý typicky obsahuje typ tokenu ("typ": "JWT") a použitý algoritmus podpisu ("alg": napr. HS256, RS256).
• payload (telo/token claims): JSON obsahujúci údaje (claims) — štandardné (exp, iat, iss, aud, nbf) aj vlastné (napr. user_id, role).
• signature (podpis): kryptografický podpis alebo MAC nad base64url(header) + "." + base64url(payload), použitý na overenie integrity a autenticity tokenu.

Všetky časti sú base64url kódované (bez '=' a so zmenenými znakmi pre URL), takže výsledný token je kompaktný a prenosný.

Príklad (zjednodušený)

Hlavička: {"alg":"HS256","typ":"JWT"}

Payload: {"sub":"12345","role":"admin","exp":1700000000}

Po zakódovaní a podpise vyzerá token ako: eyJhbGciOiJI... .eyJzdWIiOiIx... .dBjftJeZ4CVP-mB92K27uhbU

Ako sa JWT používa v praxi

• Autentifikácia: Po úspešnom prihlásení server vydá JWT klientovi, ktorý ho pripojí k následným požiadavkám (napr. v HTTP hlavičke Authorization: Bearer <token>). Server môže overiť token bez ukladania session stavu.
• Autorizácia: Token môže obsahovať role alebo oprávnenia. Server pri overení rozhodne, či má užívateľ prístup k zdroju.
• SSO a delegovanie práv: JWT sa často používa v protokoloch ako OAuth 2.0 alebo OpenID Connect na prenos identity a nárokov medzi službami.

Výhody JWT

• Bezstavovosť: server nemusí uchovávať session (škálovateľné).
• Kompaktný a prenosný: dobrý pre mobilné alebo single-page aplikácie.
• Samostatný: obsahuje potrebné informácie (čiastočne aj expiry), takže nie je potrebné dotazovať DB pri každej požiadavke (iba overenie podpisu).

Nevýhody a riziká

• Revokácia: keď je token vydaný, jeho odvolanie je zložitejšie (nie je centrálna session), preto sa odporúča krátka životnosť tokenov alebo čierne listiny (blacklist).
• Ukladanie na kliente: uloženie v localStorage je zraniteľné voči XSS. Ukladanie v HttpOnly secure cookies je bezpečnejšie.
• Únik tokenu = kompromitácia: ak útočník získa token, môže ho použiť až do vypršania platnosti.
• Nesprávne používanie: populárne chyby sú použitie alg: "none" (umožňuje obchádzanie podpisu) alebo nesprávne overovanie algoritmu/klúča.
• Nadmerné ukladanie citlivých údajov: payload nie je šifrovaný (pokým sa nepoužije JWE), preto sa do payloadu neukladajú heslá ani citlivé osobné údaje.

Algoritmy a bezpečnosť

• HS256 (HMAC + SHA256): symetrický podpis, používa zdieľaný tajný kľúč medzi stranami.
• RS256 (RSA) alebo ES256 (ECDSA): asymetrické podpisy, server podpisuje privátnym kľúčom a overuje sa verejným — bezpečnejšie pri rozdelení rolí (napr. auth server vs resource server).
• Nikdy neprijímajte tokeny s alg: "none". Pri overovaní si explicitne skontrolujte, aký algoritmus očakávate a použite silné kľúče, správne rotujte a chráňte súkromné kľúče.

Overovanie JWT na serveri — kroky

1. Dekódovať header a payload z base64url (bez automatickej dôvery).
2. Skontrolovať, či header.alg je očakávaný (a nepovoliť none).
3. Overiť podpis použitím správneho kľúča a algoritmu.
4. Skontrolovať štandardné claims: exp (platnosť), nbf (nie pred), iat (vydané), iss (vydavateľ), aud (publikum).
5. Nepoužívať údaje z payloadu bez kontroly podpisu.

Dobre praktiky pri nasadení

• Krátka životnosť access tokenov (minúty až hodiny).
• Použiť refresh tokeny (dlhšia platnosť), ktoré sa dajú bezpečnejšie uložiť a pri kompromitácii zrušiť — refresh tokeny ukladať opatrne (HttpOnly cookies).
• Rotácia kľúčov a audit prístupu.
• Neukladať citlivé údaje do payloadu; ak potrebné, používať JWE (šifrovanie).
• Používať RS/ES algoritmy, ak sú viaceré služby alebo potreba izolovať kľúče.
• Overovať issuer a audience, kontrolovať exp a nbf.

Porovnanie s klasickými sessions

• Sessions: server ukladá stav (session id), na klienta sa posiela len identifikátor. Jednoduché odvolanie (zmazať session na serveri), menší risk pri úniku tokenu (ak je id krátke a kontrolované).
• JWT: vhodné pri škálovaní a microservices, kde nechcete centrálne session úložisko. Nevýhodou je spravovanie revokácie a bezpečné ukladanie na klientoch.

Záver (praktická rada)

JWT je užitočný a flexibilný nástroj, ak sa používa správne. Pred implementáciou zvážte potrebu bezstavového riešenia, navrhnite krátku platnosť tokenov, bezpečné ukladanie a silný systém rotácie/odvolávania. Pri pochybnostiach používajte overené knižnice a dodržiavajte odporúčania pre kryptografiu a overovanie, aby ste sa vyhli bežným pastiam (alg:none, zlé kľúče, XSS).