Dekodér JWT

Co dekodér JWT vlastně dělá

JSON Web Token (JWT) vypadá jako dlouhý, neprůhledný řetězec náhodných znaků, ale není zašifrovaný a není žádnou tajnou šifrou. Je to kompaktní, URL bezpečný kontejner, který přenáší strukturovaná data mezi dvěma stranami. Vložte token do dekodéru výše a nástroj tento řetězec rozdělí a ukáže vám skutečný JSON uvnitř — metadata, nároky (claims), pro koho je token určen a kdy vyprší. Vše se odehrává přímo ve vašem prohlížeči. Token se nikdy neodesílá, neloguje ani nikam neposílá, což hraje velkou roli ve chvíli, kdy zkoumaná věc je aktivní přihlašovací pověření pro relaci.

Tři části, dvě tečky

Každý korektně formovaný JWT je tvořen třemi řetězci zakódovanými v Base64url, spojenými tečkami: hlavička.payload.podpis. Právě tento jednotlivý znak tečky umožňuje parserům poznat, kde jedna sekce končí a druhá začíná, a proto je token se špatným počtem teček odmítnut ještě dřív, než se z něj cokoliv přečte.

Hlavička je maličký objekt JSON popisující samotný token. Téměř vždy obsahuje typ (typ, obvykle JWT) a alg — podpisový algoritmus, například HS256 (HMAC se SHA-256) nebo RS256 (RSA se SHA-256). Hlavička ověřovateli přesně řekne, jak byl podpis vytvořen.

Payload je část, o kterou se zajímá většina lidí. Je to další objekt JSON obsahující claims — tvrzení o uživateli a o tokenu samotném. Specifikace claims dělí na registrované (standardní, vyhrazené názvy), veřejné a soukromé (vlastní názvy, které si vymyslíte pro svou aplikaci). Dekódování payloadu je to, co odhalí, kdo je přihlášen, jakou má roli a kdy jeho relace vyprší.

Podpis je kryptografická pečeť. Počítá se nad zakódovanou hlavičkou a payloadem pomocí algoritmu uvedeného v hlavičce plus tajného nebo soukromého klíče. Protože pokrývá obě ostatní sekce, jakákoliv změna hlavičky nebo payloadu — třeba jen jediného znaku — ho zneplatní.

Nároky (claims), se kterými se setkáte nejčastěji

Registrované claims jsou krátké, tříznakové názvy definované RFC 7519, aby spolu různé systémy dokázaly spolupracovat. Hrstka se objevuje takřka všude:

• iss — issuer (vydavatel): kdo token vydal (váš autentizační server nebo poskytovatel identity).
• sub — subject (subjekt): principál, kterého se token týká, typicky stabilní ID uživatele.
• aud — audience (příjemce): příjemce, pro kterého je token určen. API by mělo odmítnout tokeny, jejichž příjemce není ono samo.
• exp — expiration time (čas expirace): Unix timestamp, po kterém token nesmí být přijat.
• iat — issued at (vydáno v): Unix timestamp okamžiku vytvoření tokenu.

Můžete se setkat i s nbf (not before, ne dřív než) a jti (jedinečné ID tokenu). Časové značky jsou v sekundách od roku 1970 v UTC, a proto vám dekodér, který je vykresluje jako čitelná data, ušetří duševní aritmetiku při zjišťování, zda token už nevypršel.

Dekódování není totéž co ověřování — a přesně tady lidé nejčastěji naletí

Tento rozdíl je nejdůležitější věcí, kterou je o JWT třeba pochopit. Dekódování znamená přečtení obsahu: nevyžaduje žádný klíč a zvládne ho kdokoliv, kdo token drží, protože Base64url je kódování, nikoliv šifrování. Ověřování znamená prokázání, že token je autentický a neporušený — přepočítáním podpisu se správným tajným nebo veřejným klíčem a potvrzením, že se shoduje.

Tento nástroj dekóduje. Ukazuje vám, co token říká, nikoli zda je token důvěryhodný. Token může být padělaný, prošlý nebo znovu použitý (replay) a přesto se dekóduje do naprosto čistě vyhlížejícího JSON. Nikdy nedělejte rozhodnutí o autorizaci pouze na základě dekódovaných claims. V produkci ověřujete podpis na straně serveru, kontrolujete exp a potvrzujete, že iss a aud odpovídají očekávání — pomocí ověřené knihovny, nikdy ručně psaného porovnávání řetězců.

Payload není trezor

Protože payload je pouze zakódovaný v Base64url, může si ho přečíst kdokoliv, kdo token zachytí. Zacházejte se vším uvnitř jako s veřejným. Neukládejte do claims JWT hesla, celá čísla platebních karet, tajné klíče ani jakákoliv citlivá osobní data — pokud to zde dokážete jedním kliknutím dekódovat vy, dokáže to i kdokoliv jiný, kdo získá kopii. Podpis chrání proti úpravě, nikdy proti čtení. Pokud skutečně potřebujete obsah payloadu skrýt, je to úkol pro JWE (šifrované tokeny), zcela odlišnou specifikaci.

Soukromí a související nástroje

Zkoumání tokenu je citlivá činnost, proto tento dekodér běží zcela na straně klienta — parsování je čistý JavaScript ve vaší záložce a nic neopouští váš počítač. Vložení tokenu relace do nástroje běžícího na serveru znamená předat živé přihlašovací údaje třetí straně, čemuž byste se měli přesně vyhnout. Pro kódování, na kterém to vše stojí, se podívejte na náš nástroj Base64, a pro další nástroje běžící přímo ve vašem zařízení prozkoumejte zbytek našich nástrojů pro vývojáře.

Často kladené otázky