JSON Web Token se často popisuje jako způsob přihlášení, ale samotný formát uživatele nepřihlašuje. JWT je kompaktní zpráva obsahující tvrzení, například kdo token vydal, koho označuje, pro kterou službu je určen a kdy přestává platit. Příjemce může tato tvrzení přečíst a pomocí kryptografického podpisu ověřit, zda zprávu vytvořil důvěryhodný vydavatel a zda ji někdo cestou nezměnil. Bezpečnost proto nevychází z nesrozumitelného vzhledu tokenu, nýbrž z ověření podpisu a přesně definovaných pravidel přijetí.

Tři části mají různé úkoly

Běžný podepsaný JWT se skládá ze tří částí oddělených tečkami. Hlavička uvádí typ tokenu a algoritmus podpisu. Payload obsahuje tvrzení zapsaná jako JSON. Poslední část je podpis vytvořený nad přesnou zakódovanou podobou prvních dvou částí. Všechny segmenty používají Base64URL, aby token mohl bezpečně cestovat v HTTP hlavičce, cookie nebo jiném textovém kanálu.

Base64URL není šifrování. K rozbalení hlavičky a payloadu není potřeba tajný klíč ani zvláštní oprávnění. Každý držitel tokenu je může přečíst. Hesla, privátní údaje a interní tajemství proto do obyčejného podepsaného JWT nepatří, i když zakódovaný řetězec na první pohled nepřipomíná čitelný text.

Podpis chrání integritu a původ

Vydavatel podepisuje přesné bajty hlavičky a payloadu. U symetrického algoritmu používá vydavatel i ověřující služba stejné tajemství. U asymetrického algoritmu se podepisuje soukromým klíčem a ověřuje odpovídajícím veřejným klíčem. Změna jediného znaku vede k jinému výsledku ověření a manipulace je tak zjistitelná.

Platný podpis však neříká všechno. Dokazuje pouze vztah mezi daty a konkrétním klíčem. Aplikace stále musí vědět, komu klíč patří, zda je vydavatel povolený, zda byl použit očekávaný algoritmus a zda je token určen právě této službě. Kryptografie podporuje rozhodnutí o důvěře, ale sama bezpečnostní politiku nevytváří.

Standardní tvrzení vytvářejí společný slovník

Specifikace definuje známá jména jako iss pro vydavatele, sub pro subjekt, aud pro publikum, exp pro konec platnosti a nbf pro okamžik, od kterého lze token přijmout. Formát je technicky nevyžaduje, ale bezpečný systém obvykle část z nich stanoví jako povinnou.

Kontrola publika zabraňuje tomu, aby token vytvořený pro jednu službu automaticky otevřel jinou. Kontrola vydavatele vylučuje správně podepsané tokeny od nedůvěryhodné autority. Časová tvrzení omezují dobu, po kterou lze použít ukradený nebo zastaralý token. Každé tvrzení má význam jen tehdy, když ho příjemce opravdu vyhodnotí.

Proč jsou tokeny užitečné v distribuovaných systémech

Služba může JWT ověřit lokálně bez dotazu do centrální tabulky relací při každém požadavku. Veřejný klíč lze bezpečně distribuovat mnoha službám, aniž by získaly možnost vytvářet nové tokeny. To je výhodné, když několik API potřebuje uznat identitu od jednoho poskytovatele nebo když se tvrzení přenášejí přes hranice samostatně nasazovaných systémů.

Tato samostatnost má cenu. Jednou vydaný token může zůstat platný až do expirace, přestože uživatel mezitím ztratil oprávnění nebo účet byl zablokován. Krátká platnost, obnova přes refresh token, rotace klíčů a cílená revokace pomáhají riziko řídit. JWT omezuje některé sdílené dotazy, nikoli potřebu spravovat celý životní cyklus identity.

Podepisování a šifrování řeší jiné problémy

Většina JWT používaných v API je pouze podepsaná. Obsah zůstává viditelný, zatímco podpis chrání před změnou a potvrzuje původ. Příbuzný standard JWE umí obsah zašifrovat, přináší však další rozhodnutí o klíčích, příjemcích a interoperabilitě. Šifrování má smysl při jasném požadavku na důvěrnost, ne jako náhrada za omezení množství dat v tokenu.

I zašifrovaný bearer token je nutné chránit před krádeží. Služba obvykle přijímá jeho držitele bez dalšího důkazu totožnosti. Utajení payloadu tedy neřeší bezpečný transport, ukládání ani únik tokenu do logů.

Ověřování musí být záměrně přísné

Aplikace má vybírat povolené algoritmy z konfigurace a nesmí slepě následovat hlavičku příchozího tokenu. Musí ověřit podpis, vydavatele, publikum, časová omezení a všechna doménová tvrzení, na nichž staví autorizaci. Výběr klíče musí zůstat v důvěryhodném seznamu, aby útočník nemohl ověření nasměrovat na vlastní soubor nebo vzdálenou adresu.

Chybové odpovědi mají klientovi sdělit, že pověření není přijatelné, ale nemají odhalovat kryptografické detaily. Provozní log může zaznamenat typ selhání a identifikátor bezpečného pravidla, nikoli celý živý bearer token. Každý, kdo token získá, jej totiž může zkusit použít.

JWT je podepsaná zpráva, ne kouzelná identita

Token funguje dobře tam, kde je potřeba přenosná a nezávisle ověřitelná sada tvrzení. Jeho kompaktní forma a široká podpora knihoven usnadňují integraci, ale spolehlivost stojí na důvěryhodných klíčích, správné validaci, omezené životnosti a promyšlené autorizaci.

Architektura má také určit, kdo odpovídá za změny smlouvy. Přidání povinného claimu, nového publika nebo jiného způsobu rotace není lokální detail knihovny. Ovlivňuje vydavatele i všechny příjemce a potřebuje kompatibilní rollout, telemetrii odmítnutých tokenů a možnost návratu. Jinak může bezpečnostní zpřísnění způsobit plošný výpadek, nebo se kvůli obavě z výpadku nikdy skutečně nevynutí.

Stejnou pečlivou provozní a bezpečnostní péči vyžaduje ukončení staré verze, aby nezůstala trvale otevřená méně přísná cesta přijetí tokenu.

Pohled na JWT jako na podepsanou zprávu odstraňuje nejčastější omyly. Obsah není tajný, platnost závisí na kontextu a samotné držení může poskytovat přístup. S těmito vlastnostmi může být JWT užitečným stavebním prvkem. Bez nich se z něj stává jen složitější řetězec, kterému aplikace důvěřuje bez dostatečného důvodu.