Co je uvnitř JWT a proč dekódování neznamená ověření

JSON Web Token (JWT) jsou tři textové části spojené tečkami: hlavička, payload a podpis. První dvě jsou pouze zakódované, ne zašifrované, takže je může přečíst každý, kdo token drží. Podpis umožňuje serveru ověřit, že token vydala důvěryhodná strana a že ho nikdo nezměnil. Dekódování tokenu vám řekne, co tvrdí. Teprve ověření vám řekne, zda mu věřit.

Dekodér JWTToken vypršel, nebo je platný?Vyzkoušet zdarma

Tři části

Token vypadá takto: header.payload.signature. První část známého ukázkového tokenu z jwt.io je:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Každá z prvních dvou částí je JSON převedený do base64url, tedy textové podoby bezpečné pro použití v URL. První část se dekóduje na:

{"alg":"HS256","typ":"JWT"}

Payload stejného příkladu se dekóduje na:

{"sub":"1234567890","name":"John Doe","iat":1516239022}

Payload obsahuje tvrzení (claims), tedy výroky o uživateli nebo relaci. Podpis se počítá z prvních dvou částí a klíče, takže změna jediného znaku ho zneplatní. Base64url se obrátit bez klíče lze, proto nikdy do payloadu nedávejte heslo, privátní klíč ani osobní údaje.

Registrovaná tvrzení

RFC 7519, standard pro JWT, vyhrazuje několik krátkých názvů tvrzení:

iss (vydavatel): kdo token vytvořil.
sub (subjekt): ke komu se token vztahuje, obvykle ID uživatele.
aud (příjemce): služba, pro kterou je token určen.
exp (čas vypršení): okamžik, od kterého je token neplatný.
nbf (ne dříve než): nejdřívější okamžik, kdy je token platný.
iat (čas vydání): kdy byl token vytvořen.

Časy jsou sekundy od 1. ledna 1970 UTC, tzv. Unixový čas. Příklad nemá exp, takže podle standardu nikdy nevyprší. Skutečný token by ho mít měl. Další názvy, například role nebo email, patří aplikaci.

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

Dekódování rozdělí token podle teček, obrátí base64url a přečte JSON. Ukáže, co token tvrdí, a totéž udělá i u padělaného tokenu, protože kdokoli může napsat libovolná tvrzení s libovolným podpisem.

Ověření znovu spočítá podpis se správným klíčem a zkontroluje, že sedí. Dále ověří, že aktuální čas leží mezi hodnotami exp a nbf a že iss a aud mají hodnoty, které služba očekává. Aplikace, která přečte tvrzení role bez ověření, důvěřuje tomu, kdo token napsal. To je běžná chyba.

HS256, RS256 a ES256

Hodnota alg určuje metodu. Běžné jsou tři:

HS256 je HMAC se SHA-256. Jedno sdílené tajemství podepisuje i ověřuje, takže zůstává na serveru, který tokeny vydává.
RS256 je podpis RSA se SHA-256. Vydavatel podepisuje privátním klíčem a kdokoli s veřejným klíčem může ověřovat. Jiné služby tak mohou tokeny kontrolovat, aniž by je mohly vytvářet.
ES256 je podpis ECDSA s křivkou P-256 a SHA-256. Funguje jako RS256, ale s menšími klíči a podpisy.

Použijte HS256, když jedna služba tokeny vydává i kontroluje. Použijte RS256 nebo ES256, když musí jiné služby kontrolovat tokeny, které sama nevydala.

Problémy plynoucí z důvěry hlavičce

Hlavičku píše ten, kdo token posílá, takže ověřovatel nesmí nechat, aby o pravidlech rozhodovala ona.

alg: none. Token bez podpisu může deklarovat "alg":"none". Některé knihovny takové tokeny kdysi přijímaly a kontrolu přeskočily. Povolené algoritmy nastavte ve vlastním kódu, nikdy je nepřebírejte z tokenu.
Záměna algoritmu. Server očekává RS256 a má veřejný klíč. Útočník pošle token HS256 podepsaný tímto veřejným klíčem jako HMAC tajemstvím. Ověřovatel, který přijme jakýkoli algoritmus uvedený v hlavičce, ho přijme. Každý klíč přiřaďte přesně jednomu algoritmu.
Slabá tajemství. Útočník má hlavičku, payload i podpis, takže může kandidátní tajemství zkoušet offline. Krátké tajemství nebo běžné slovo podlehne takovému seznamu rychle. RFC 7518 uvádí, že klíč HS256 má mít alespoň 256 bitů a být náhodný.

Vkládání produkčního tokenu na web

Platný, nevypršelý token funguje pro každého, kdo ho drží, dokud nevyprší. Zacházejte s ním jako s heslem. Než token vložíte na nějaký web, zjistěte, zda ho web posílá na server. Nástroj, který běží celý v záložce prohlížeče, to nepotřebuje. Libovolnou stránku můžete zkontrolovat v nástrojích pro vývojáře v prohlížeči, kde sledujete síťové požadavky.

Tokeny obvykle nejde zneplatnit před vypršením, pokud server nevede seznam. Pokud se živý token dostane na veřejnost, požádejte službu o zrušení relace nebo výměnu klíčů. Kde můžete, použijte pro ladění token z testovacího prostředí. Dekodér JWT načte tři části přímo v záložce prohlížeče a nic, co vložíte, se nikam neodešle.

Webhooky: stejná myšlenka se sdíleným tajemstvím

Většina poskytovatelů webhooků posílá v hlavičce HMAC těla požadavku, spočítaný z tajemství, které s nimi sdílíte. Váš přijímač spočítá stejný HMAC a obě hodnoty porovná. Časté chyby bývají drobné. JSON se před hašováním znovu naformátuje, takže se změní bajty. Testovací tajemství se použije proti živému provozu. Nebo se podpisy porovnávají obyčejnou rovností řetězců, což může prozradit informace o časování. Použijte porovnání v konstantním čase.

Kontrola podpisu webhooku spočítá podpis z tajemství a těla, které vložíte, pro GitHub, Stripe, Slack, Shopify nebo jakékoli jiné schéma HMAC, takže uvidíte, zda se obě hodnoty shodují.

Stručné odpovědi

Je JWT zašifrovaný?

Ne. Standardní JWT je podepsaný a kdokoli může přečíst jeho hlavičku a payload. Před změnami chrání pouze podpis.

Co se stane, když upravím payload?

Podpis přestane sedět a ověřující server token odmítne. Čtení tvrzení podpis nekontroluje, takže dekodér stále ukáže vaši upravenou verzi.