Úspěšný útok na JWT obvykle nevyžaduje prolomení moderní kryptografie. Častější příčinou je aplikace, která ověří příliš málo, přijme nesprávný klíč, uloží bearer token na nevhodné místo nebo očekává, že samostatný token bude mít stejné vlastnosti jako relace řízená serverem. Kompaktní formát může zakrýt skutečnost, že kolem něj vzniká celý autentizační systém se správou klíčů, expirací, revokací a autorizací.

Dekódování není ověření

Hlavičku a payload lze dekódovat bez klíče. Některé implementace je přečtou a použijí dříve, než ověří podpis. Útočník si přitom může vytvořit libovolný token, vložit do něj cizí identifikátor nebo roli správce a zakódovat jej stejným způsobem. Dokud ověření úspěšně neskončí, jsou všechna tvrzení nedůvěryhodným vstupem.

Kontrola podpisu musí předcházet autorizační logice. Následovat má přesné ověření vydavatele, publika, expirace, začátku platnosti a doménových omezení. Částečně validovaný token se nemá předávat dál s nadějí, že další vrstva doplní zbytek.

Token nesmí určovat bezpečnostní politiku

Hlavička uvádí algoritmus, ale příjemce jej musí porovnat s vlastním allowlistem pro konkrétního vydavatele a klíč. Historické chyby vznikaly, když knihovna přijala nepodepsaný token nebo zaměnila symetrický a asymetrický režim. Bezpečná konfigurace přesně říká, které kombinace jsou povolené, a ostatní odmítne.

Opatrnost vyžaduje i kid, identifikátor klíče. Pomáhá při rotaci, ale nesmí se změnit v nekontrolovanou cestu k souboru, fragment SQL dotazu nebo adresu libovolného serveru. Výběr klíče musí probíhat pouze uvnitř důvěryhodné sady publikované očekávanou autoritou.

Bearer token je plnohodnotné pověření

Většina access tokenů funguje na principu držitele: kdo token předloží, může získat přístup. Podpis neurčuje, kdo jej právě poslal. Token může uniknout do aplikačních logů, analytiky, chybového reportu, historie prohlížeče, URL nebo příkazu zkopírovaného do veřejného ticketu.

Přenos má probíhat přes TLS, token nepatří do query parametrů a autorizační hlavičky je nutné v logování redigovat. V prohlížeči je potřeba hodnotit současně riziko XSS a CSRF. Žádné úložiště neopraví zranitelnou aplikaci, proto je důležité omezit dobu i rozsah použitelnosti pověření.

Dlouhá platnost komplikuje revokaci

Samostatný token může dál fungovat po změně hesla, odchodu zaměstnance nebo odebrání role. Týdenní access token dává útočníkovi až týden času, pokud každá služba neprovádí další centrální kontrolu. Taková kontrola je možná, ale vrací do architektury sdílený stav, který měl JWT původně omezit.

Krátce platné access tokeny zmenšují okno rizika. Delší refresh token může získávat nové tokeny přes kontrolovaný endpoint a podporovat rotaci i revokaci. Citlivé události mohou vyžadovat zrušení celé rodiny obnovovacích tokenů nebo kontrolu verze relace uložené u účtu.

Payload má být minimální

Podepsaný payload je čitelný, takže do něj nepatří hesla, soukromé klíče ani důvěrné profily. I běžné osobní údaje je vhodné omezit, protože token prochází klienty a službami a může zůstat v diagnostických systémech déle než původní záznam. Minimalizace snižuje dopad úniku i nároky na ochranu dat.

Velký token také zvyšuje každý požadavek, může překročit limit proxy nebo cookie a nese zastaralý stav. Obsahovat má jen tvrzení, která příjemce opravdu potřebuje. Proměnlivé údaje je často lepší načíst z autoritativní služby než je kopírovat do pověření na dlouhou dobu.

Podpis nenahrazuje autorizaci objektu

Role nebo scope v tokenu poskytuje kontext, ale aplikace stále musí ověřit oprávnění ke konkrétnímu projektu, tenantovi či dokumentu. Podepsané tvrzení editor neznamená právo upravit všechny objekty v systému. Pravidla přístupu musí spojit identitu s aktuálními doménovými daty a požadovanou operací.

Víceklientské systémy mají porovnávat tenant claim s routingem a účtem, nikoli přijmout první podepsanou hodnotu. JWT validace vytváří důvěryhodný identitní kontext; konečné rozhodnutí o akci stále patří aplikační vrstvě.

Rotace klíčů se plánuje před incidentem

Klíče stárnou, mohou uniknout a někdy je nutné je rychle nahradit. Vydavatel má chránit soukromé klíče, publikovat aktuální veřejné klíče a ponechat dostatečný překryv, aby doběhly tokeny podepsané předchozí verzí. Ověřující služby potřebují rozumnou cache, která se obnoví včas, ale neselže při krátkém výpadku endpointu.

Nouzový postup musí určit, jak se kompromitovaný klíč vyřadí, které tokeny přestanou platit a jak se změna rozšíří ke všem příjemcům. Praktický nácvik je spolehlivější než dokument, který nikdo nepoužil.

Testy musí dokazovat také odmítnutí

Ověřování má zajišťovat udržovaná knihovna s explicitní konfigurací. Testy nemají ukazovat jen úspěšné přihlášení. Musí potvrdit odmítnutí změněného payloadu, cizího vydavatele, nesprávného publika, expirovaného tokenu, neočekávaného algoritmu a podpisu nesouvisejícím klíčem.

Produkční metriky mají odlišit běžnou expiraci od neznámého vydavatele, chybějícího klíče nebo opakovaných neplatných podpisů. Prudká změna může znamenat chybný rollout, zastaralou cache klíčů i probíhající útok. Alert však nesmí obsahovat samotný token. Stačí bezpečný otisk události, jméno pravidla a kontext služby, který dovolí incident spojit napříč systémy.

Pravidelná bezpečnostní revize celé sdílené konfigurace navíc odhalí příjemce, kteří stále povolují vyřazený algoritmus, tolerují příliš velký časový posun nebo neověřují nové publikum. Centrální knihovna pomáhá, ale každá služba musí prokázat, že používá její aktuální bezpečné nastavení.

Bezpečná implementace JWT je záměrně přísná. Ví přesně, kdo smí token vydat, které klíče a algoritmy přijímá, kde se token smí použít a jak dlouho. Vše ostatní odmítá, i když lze řetězec bez problému dekódovat a jeho obsah na první pohled vypadá rozumně.