JWT Decoder

Vložte libovolný JWT token a okamžitě uvidíte jeho dekódovanou hlavičku a datovou část ve formátu JSON.

Náš dekodér:

• identifikuje podpisový algoritmus
• zobrazí všechny standardní i vlastní nároky
• převede unixová časová razítka na data čitelná pro člověka

Barevně odlišené zobrazení usnadňuje rozlišení tří částí JWT.

Laděte problémy s JWT kontrolou doby platnosti, časových razítek vydání a hodnot nároků.

Náš nástroj ukazuje, zda tokeny vypršely, jak dlouho zbývá do vypršení platnosti, a upozorňuje na potenciální problémy.

Nezbytné pro:

• vývoj API
• ladění ověřování
• bezpečnostní audity

Koncept JSON Web Token (JWT) je kompaktní způsob přenosu nároků mezi dvěma stranami bezpečný pro URL, definovaný v RFC 7519 od IETF.

JWT má tři části oddělené tečkami, přičemž každá je kódována v Base64URL dle RFC 4648:

• hlavička, která pomocí JSON (RFC 8259) deklaruje podpisový algoritmus a typ tokenu
• datová část, která nese nároky — tvrzení o entitě, jako je uživatel, plus metadata, například platnost
• podpis, který spojuje hlavičku a datovou část dohromady, takže je detekovatelná jakákoli manipulace

Tato struktura umožňuje službám ověřovat totožnost bez vyhledávání v databázi, což je důvod, proč jsou JWT běžné v bezstavovém ověřování a tocích OpenID Connect.

Chcete-li dekódovat JWT, rozštěpte token na jeho dvou tečkách na tři segmenty a poté dekódujte první dva pomocí Base64URL.

První segment přináší JSON hlavičky a druhý JSON datové části, přičemž oba jsou čitelné jako prostý text podle RFC 8259.

Base64URL (RFC 4648, sekce 5) nahrazuje '+' za '-' a '/' za '_' a vynechává zarovnání, takže standardní dekodér Base64 může bez úprav selhat. Náš nástroj to zvládá automaticky a výsledek hezky formátuje.

Třetí segment, podpis, se do textu nedekóduje, protože jde o surovou kryptografickou hodnotu.

Jak uvádí dokumentace MDN Web Docs, dekódování není ověření — přečtení datové části nikdy nepotvrzuje, že je token autentický.

Ne — standardní podepsaný JWT (JWS) je kódovaný, nikoli šifrovaný, takže kdokoli drží token, může si přečíst jeho datovou část.

Kódování Base64URL (RFC 4648) je reverzibilní a neposkytuje žádnou důvěrnost; pouze umožňuje přenos bezpečný pro binární data. Podpis popsaný v RFC 7515 (JSON Web Signature) chrání integritu a autentičnost, nikoli tajnost.

Pokud potřebujete obsah skrýt, použijte raději JWE (JSON Web Encryption, RFC 7516).

OWASP i IETF tento rozdíl zdůrazňují: nikdy neumisťujte hesla, tajné klíče API ani osobně identifikovatelné údaje do datové části podepsaného JWT, protože dekodér, jako je tento, odhalí každý nárok v prostém textu bez jakéhokoli klíče.

Registrované JWT nároky jsou standardizovány v RFC 7519, aby je různé systémy interpretovaly konzistentně.

Základní sada obsahuje:

• 'iss' (vydavatel)
• 'sub' (předmět, subjekt tokenu)
• 'aud' (okruh uživatelů, zamýšlený příjemce)
• 'exp' (doba platnosti)
• 'nbf' (ne dříve než)
• 'iat' (čas vydání)
• 'jti' (jedinečné ID tokenu)

Hodnoty exp, nbf a iat jsou hodnoty NumericDate — sekundy od unixové epochy —, které náš dekodér převádí na data čitelná pro člověka. Aplikace přidávají vlastní (soukromé) nároky pro role, rozsahy nebo ID tenantů.

Podle specifikace musí ověřovatelé odmítnout token, jehož 'exp' vypršelo nebo jehož 'aud' neodpovídá očekávanému příjemci, čímž se brání zneužití napříč službami.

Podpisové algoritmy JWT jsou definovány v RFC 7518 (JSON Web Algorithms) a jsou identifikovány hodnotou 'alg' v hlavičce.

• Algoritmy HMAC (HS256, HS384, HS512) používají jeden sdílený tajný klíč pro podepisování i ověřování, což je jednoduché, ale vyžaduje, aby tento tajný klíč držel každý ověřovatel.
• Algoritmy RSA (RS256, RS384, RS512) a RSASSA-PSS (PS256) používají k podpisu soukromý klíč a k ověření veřejný klíč, což je ideální pro distribuované systémy a OpenID Connect.
• Algoritmy ECDSA (ES256, ES384, ES512) nabízejí srovnatelnou bezpečnost s menšími klíči a podpisy.

NIST publikuje podkladové standardy SHA-2 a ECDSA. Náš dekodér čte pole 'alg', abyste mohli potvrdit, které schéma token používá.

JWT se v moderních API široce využívají pro bezstavovou autentizaci, autorizaci a zabezpečenou výměnu informací.

Poté, co se uživatel přihlásí, server vydá podepsaný JWT, který klient vrací v hlavičce HTTP Authorization jako Bearer token podle specifikace RFC 6750. Jelikož je podpis obsažen přímo v tokenu, backendové služby jej mohou ověřit bez nutnosti dotazovat se úložiště relací (session store), což zvyšuje škálovatelnost.

JWT také pohánějí ID tokeny protokolu OpenID Connect a vzory přístupových tokenů v OAuth 2.0.

Vývojáři používají dekodéry při ladění k nahlédnutí do nároků (claims), ověření hodnot příjemce a vydavatele a ke kontrole platnosti, když API vrací chybu 401. Jak popisuje dokumentace MDN Web Docs, tento tokenový tok tvoří základ mnoha architektur s jednotným přihlášením (SSO) a mikroslužeb.

Bezpečné používání JWT se opírá o ověřování algoritmu, kontrolu podpisu a vynucování vypršení platnosti.

OWASP varuje před klasickým útokem typu 'alg: none' a útoky zaměřenými na záměnu algoritmů, kdy lze zfalšovat token na serveru, který je oklamán a považuje veřejný klíč RS256 za tajný klíč HMAC; vždy raději napevno nastavte očekávaný algoritmus, než abyste slepě důvěřovali hlavičce.

Klíčové postupy:

• Používejte krátkou dobu platnosti ('exp') v kombinaci s obnovovacími tokeny (refresh tokens) a u každého požadavku ověřujte 'iss' a 'aud'.
• Nikdy neukládejte citlivé údaje do datové části (payload), protože ta je pouze zakódovaná v Base64.
• Přenášejte tokeny výhradně přes HTTPS a zvažte strategie pro jejich zneplatnění, protože standardní JWT nelze před vypršením platnosti jednotlivě odvolat.

Dodržování těchto doporučení od IETF a OWASP pomáhá eliminovat nejčastěji zneužívané slabiny JWT.

Mezi nejčastější chyby při práci s JWT patří:

• Zaměňování dekódování s ověřením: čtení datové části pomocí dekodéru neprokazuje vůbec nic o pravosti, protože kdokoli může vytvořit nepodepsaný nebo zfalšovaný token.
• Slepá důvěra v hodnotu 'alg' v hlavičce, což otevírá cestu k útokům se záměnou algoritmů, na které upozorňuje OWASP.
• Chybné čtení doby platnosti porovnáním sekund od epochy ('exp') s milisekundami, což způsobuje, že platné tokeny vypadají jako vypršené.
• Použití standardního dekodéru Base64 namísto Base64URL (RFC 4648), což může kvůli jiné abecedě a chybějícímu zarovnání poškodit výstup.
• Umístění citlivých údajů do datové části, čímž dochází k jejich úniku, protože token je pouze zakódován, nikoli šifrován.

Ověřování podpisů na straně serveru pomocí správného klíče a algoritmu těmto problémům předchází.

Tento dekodér JWT zpracovává tokeny výhradně na straně klienta, takže váš token nikdy neopustí vaše zařízení ani neputuje na žádný server.

Protože podepsaný JWT je zakódován pouze pomocí Base64URL (RFC 4648), nevyžaduje dekódování žádné síťové volání – hlavička a datová část se v prohlížeči jednoduše převedou zpět ze zakódovaného tvaru pomocí JavaScriptu.

Toto lokální zpracování je klíčové pro bezpečnost: tokeny často obsahují přihlašovací údaje k aktivní relaci a jejich vložení do nástroje na straně serveru by je mohlo vystavit v protokolech nebo při přenosu. OWASP doporučuje minimalizovat místa, kudy citlivé přihlašovací údaje putují.

Dekodér běžící čistě v prohlížeči umožňuje vývojářům bezpečně kontrolovat produkční tokeny při ladění, přičemž dodržuje zásadu minimálních oprávnění bez nutnosti odesílat autorizační data třetí straně.