JWT vs. session cookies: kterou autentizaci zvolit pro web a API

„Použijeme JWT, protože je moderní“ je jedna z nejčastějších architektonických chyb malých projektů. JWT i klasické session mají své místo. Rozhodnutí by mělo vycházet z toho, kdo je klient, jak rychle potřebujete odhlásit uživatele a kolik serverů ověřuje přihlášení.

Jak funguje session

1. Uživatel se přihlásí jménem a heslem.
2. Server vytvoří záznam session (v paměti, Redisu nebo databázi) a vygeneruje náhodné ID.
3. ID pošle v cookie, prohlížeč ho automaticky přikládá ke každému požadavku.
4. Server podle ID najde session a ví, kdo je přihlášený.

Set-Cookie: sid=Yf3k...9Qa; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=1209600

Cookie obsahuje jen náhodný identifikátor, žádná data. Stav drží server.

Jak funguje JWT

JSON Web Token se skládá ze tří částí oddělených tečkou: hlavička, payload a podpis, každá zakódovaná Base64URL.

{
  "sub": "user_42",
  "role": "admin",
  "iat": 1760270400,
  "exp": 1760271300
}

Server token podepíše (HMAC tajným klíčem, nebo RSA/ECDSA soukromým klíčem) a předá klientovi. Ten ho posílá typicky v hlavičce:

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Server ověří podpis a expiraci a nemusí se nikam dívat – token je bezstavový. Payload ale není šifrovaný, jen podepsaný. Kdokoli ho dekóduje, proto do něj nepatří citlivé údaje.

Srovnání

	Session	JWT
Stav	na serveru	v tokenu
Okamžité odhlášení	ano, smažete session	ne bez blacklistu nebo krátké expirace
Změna rolí	projeví se hned	až po vydání nového tokenu
Ověření na více službách	sdílené úložiště (Redis)	stačí veřejný klíč
Velikost	desítky bajtů	stovky bajtů a víc
Mobilní aplikace, třetí strany	jde, ale méně přirozeně	přirozené

Kdy použít session

• Klasická webová aplikace nebo SPA na stejné doméně jako backend.
• Potřebujete okamžitě odhlásit uživatele (změna hesla, zablokování účtu, „odhlásit všechna zařízení“).
• Máte jeden backend nebo sdílený Redis.

Většina frameworků (Laravel, Django, Rails, Express s express-session) to umí bez další práce a s bezpečnými výchozími hodnotami.

Kdy použít JWT

• API pro mobilní aplikace a externí klienty.
• Více nezávislých služeb, které ověřují identitu bez dotazu na centrální server.
• Krátkodobé tokeny mezi službami (service-to-service).
• Standardizované protokoly – OAuth 2.0 / OpenID Connect (ID token je vždy JWT).

Bezpečné nastavení session cookie

• HttpOnly – JavaScript cookie nepřečte, takže ji neukradne XSS.
• Secure – posílá se jen přes HTTPS.
• SameSite=Lax – chrání před většinou CSRF útoků; pro formuláře měnící data navíc používejte CSRF token.
• Po přihlášení vygenerujte nové ID session (ochrana proti session fixation).
• Nastavte absolutní i neaktivní expiraci.

Bezpečné používání JWT

• Krátká platnost access tokenu, typicky 5–15 minut.
• Refresh token s delší platností uložený na serveru (v databázi), aby šel zneplatnit. Při každém použití ho vyměňte za nový (rotace) a opakované použití starého berte jako známku krádeže.
• Vynuťte algoritmus při ověření. Nikdy nedůvěřujte hodnotě alg z hlavičky tokenu – historicky to vedlo k útokům s alg: none.
• Kontrolujte exp, iss a aud.
• HMAC klíč musí být dlouhý a náhodný (alespoň 256 bitů), ne „secret“.

Ověření v Node.js s knihovnou jsonwebtoken:

import jwt from "jsonwebtoken";

function verifyToken(token) {
  return jwt.verify(token, process.env.JWT_SECRET, {
    algorithms: ["HS256"],
    issuer: "https://api.example.cz",
    audience: "example-web",
  });
}

Funkce vyhodí výjimku při neplatném podpisu, expiraci nebo nesouhlasícím iss/aud.

Kam uložit JWT v prohlížeči

localStorage je dostupný každému JavaScriptu na stránce – při XSS je token pryč. Pokud JWT v prohlížeči používáte, je bezpečnější uložit ho do HttpOnly cookie. Tím se ale zase dostáváte k cookies a CSRF a velká část výhod JWT mizí. Pro webovou aplikaci na vlastní doméně proto bývá session jednodušší a bezpečnější volba.

Hybrid, který funguje

Častý a rozumný vzor:

• Web používá session cookie.
• Veřejné API pro integrace používá dlouhé náhodné API klíče (uložené na serveru jako hash) nebo OAuth.
• Interní služby si předávají krátkodobé JWT.

Rozhodovací otázky

1. Je klient prohlížeč na stejné doméně? → session.
2. Musím umět uživatele odhlásit okamžitě? → session, nebo JWT s krátkou expirací a revokovatelným refresh tokenem.
3. Ověřuje token více nezávislých služeb? → JWT s asymetrickým podpisem.
4. Implementuji přihlášení přes Google/Microsoft? → OpenID Connect, tedy JWT, ale vydané poskytovatelem identity.

Ať zvolíte cokoli, hesla ukládejte správně – viz hashování hesel.