Co je to JWT? Pochopení webových tokenů JSON a bezstavového ověřování

Když se přihlásíte do moderní jednostránkové aplikace (jako React nebo Vue) nebo do mobilní aplikace, server potřebuje způsob, jak si zapamatovat, kdo jste. Tradičně to dělalo ukládáním „ID relace“ do rozsáhlé databáze na serveru a ukládáním cookie do vašeho prohlížeče. Pokaždé, když kliknete na tlačítko, server musel vyhledat toto ID ve své databázi. Tomu se říká stavová autentizace.

V éře mikroslužeb a cloudového škálování se však databáze staly úzkým hrdlem. K vyřešení tohoto problému vývojáři přijali bezstavové ověřování prostřednictvím JSON Web Tokens (JWT). S JWT si server nemusí pamatovat, kdo jste – váš prohlížeč serveru sdělí, kdo přesně jste, a prokáže to pomocí kryptografie.

Anatomie JWT

Pokud po přihlášení do moderní aplikace zkontrolujete síťový provoz, pravděpodobně uvidíte záhlaví „Authorization: Bearer“ následované dlouhým, náhodně vypadajícím řetězcem znaků odděleným dvěma tečkami. To je JWT.

JWT se skládá přesně ze tří částí: Header.Payload.Signature.

1. Záhlaví

První částí je objekt JSON kódovaný Base64URL, který jednoduše popisuje token. Obvykle obsahuje dvě vlastnosti: typ tokenu (JWT) a používaný podepisovací algoritmus (například HMAC SHA256 nebo RSA).

2. Užitečné zatížení (nároky)

Prostřední část je také objekt JSON kódovaný Base64URL. Zde žijí skutečná data. Tyto údaje se nazývají „nároky“. Může například obsahovat vaše ID uživatele, vaši roli (např. „Správce“) a časové razítko vypršení platnosti. Protože je toto užitečné zatížení připojeno ke každému požadavku, server okamžitě ví, kdo jste, aniž by se dotazoval na databázi.

KRITICKÉ VAROVÁNÍ: Obsah je pouze zakódován, ne zašifrován. Každý, kdo zachytí JWT, jej může snadno dekódovat a přečíst užitečné zatížení. Nikdy neukládejte hesla, rodná čísla ani citlivá data uvnitř užitečného obsahu JWT.

3. Podpis

Pokud může kdokoli číst a upravovat obsah, co brání uživateli se zlými úmysly ve změně role z „Uživatel“ na „Správce“? Odpověď je Podpis.

K vytvoření podpisu server vezme záhlaví, datovou část a vysoce bezpečný tajný klíč (známý pouze serveru) a spustí je pomocí kryptografického algoritmu (jako SHA256). Výsledný hash se stane podpisem.

Když server obdrží token zpět od klienta, přepočítá podpis pomocí svého tajného klíče. Pokud uživatel manipuloval s datovou částí (i když změnil jediné písmeno), přepočítaný podpis se nebude shodovat s podpisem na tokenu a server požadavek okamžitě odmítne jako podvodný.

Proč Microservices milují JWT

Představte si společnost jako Netflix. Mají ověřovací server, server pro streamování videa a fakturační server. Pokud by používali tradiční relace, každý jednotlivý server by musel neustále komunikovat s centrální databází, aby zkontroloval, zda je uživatel přihlášen.

U JWT podepisuje ověřovací server token pomocí soukromého klíče. Uživatel poté předá tento token přímo na Video server. Protože Video server má veřejný klíč, může nezávisle ověřit podpis. Video server přesně ví, kdo je uživatel, aniž by kdy mluvil s autentizačním serverem nebo databází. To umožňuje infrastruktuře nekonečně škálovat bez překážek.

The Dark Side: Token Invalidation

JWT nejsou dokonalé. Jejich největší síla (bez státní příslušnosti) je zároveň jejich největší slabinou. Protože server neuchovává záznamy o aktivních tokenech, nemůžete snadno odhlásit uživatele nebo zneplatnit konkrétní token před vypršením jeho platnosti.

Pokud hacker ukradne JWT uživatele, hacker má plný přístup, dokud nevyprší časové razítko vypršení platnosti tokenu. Ke zmírnění tohoto rizika používají bezpečnostní inženýři systém dvou tokenů:

• Přístupové tokeny: JWT s krátkou životností (např. 15 minut) používané pro požadavky API.
• Obnovit tokeny: Bezpečně uložené tokeny s dlouhou životností, používané výhradně k vyžádání nových přístupových tokenů. Pokud je účet kompromitován, server zruší obnovovací token a hackerův přístupový token přirozeně zemře do 15 minut.

Často kladené otázky (FAQ)