Slovník pojmů

JWT

JWT se dá snadno dekódovat, ale to z něj nedělá důvěryhodný token. Před rozhodnutím o přístupu se ověřuje kryptografická ochrana i očekávané claims.

Stručná definice

Kompaktní obálka pro ověřitelné claims.

Běžný podepsaný JWT, označovaný jako JWS, má header, payload a signature oddělené tečkami. Header a payload jsou kódované Base64URL, nikoli šifrované: lze je přečíst, ale před úspěšným ověřením podpisu jim aplikace nesmí věřit.

JWT může být také šifrovaný jako JWE, který chrání důvěrnost obsahu. Podpis a šifrování jsou odlišné vlastnosti. JWT není synonymem OAuth 2.0, access tokenu ani serverové session; je to standardizovaný formát, který lze použít v různých protokolech.

Použití

Kdy JWT nese identitu nebo oprávnění

Token má mít konkrétního vydavatele, příjemce a krátce vymezený účel.

access token pro chráněné backendové API
ID token vydaný OpenID Connect providerem
krátkodobé tokeny mezi službami s jasnou audience
přenos ověřitelných claims bez databázového dotazu při každém requestu
rotace veřejných ověřovacích klíčů přes JWKS

Praktický příklad

API ověřuje access token pro import objednávek

B2B klient pošle access token pro importní API. API z důvěryhodné konfigurace zná issuer a svou audience, podle kid vybere klíč z příslušného JWKS a ověří pevně povolený algoritmus, podpis, issuer, audience i expiraci.

Až potom povolí scope pro import a ověří, že klient pracuje s konkrétním tenantem. Token se neparsuje ručně kvůli kryptografii a log obsahuje jen bezpečný korelační údaj, ne celý JWT.

Jak funguje

Od vydání tokenu k autorizaci API

Token nejprve zůstává nedůvěryhodným vstupem. Autorizace přichází až po validaci.

Vydání Důvěryhodný issuer vytvoří claims s účelem a omezenou životností, token podepíše jako JWS nebo podle potřeby zašifruje jako JWE.
Předání Klient token předá chráněnému API jako credential; token nepatří do URL, logů ani chybových zpráv.
Výběr klíče API podle předem důvěryhodného issueru a kid zvolí odpovídající klíč z nakonfigurované sady nebo JWKS.
Ověření Použije pevně povolený algoritmus, ověří ochranu tokenu, iss, aud, exp, případně nbf a očekávaný typ tokenu.
Rozhodnutí Teprve po validaci kontroluje scope či aplikační oprávnění nad konkrétním tenantem a daty.

Důležité pojmy

Části tokenu a jejich hranice

Kryptografická validace je nutná, ale sama nenahrazuje obchodní autorizaci.

Claims

iss je vydavatel, sub subjekt, aud příjemce, exp konec platnosti, nbf začátek platnosti, iat čas vydání a jti identifikátor. Aplikace musí určit, které claims očekává a co znamenají.

Decode a verify

Decode jen rozbalí strukturu. Verify ověřuje podpis nebo šifrování i kontext tokenu. Decodovaný payload nemá řídit přístup.

Algoritmus a klíč

Algoritmus z neověřené hlavičky není instrukce pro aplikaci: verifikátor používá allowlist a správný typ klíče. Nesmí přijmout alg none ani libovolnou URL klíče.

JWKS a rotace

JWKS zveřejňuje sadu veřejných klíčů; důvěru jim aplikace dává až přes předem nakonfigurovaný issuer nebo ověřené Discovery. Nový klíč se zpřístupní dřív, než se jím začnou podepisovat tokeny; předchozí zůstává po dobu platnosti starých tokenů.

Vztah k podobným pojmům

Formát tokenu neurčuje jeho účel.

Stejný JWT může mít v různých protokolech jiná pravidla i audience.

OAuth 2.0: Autorizační framework, který může používat JWT i opaque access token. OAuth není formát tokenu.
OpenID Connect: Často vydává ID token jako JWT pro konkrétní klientskou aplikaci. ID token není obecný bearer token pro API.
Serverová session: Alternativa, kde stav a okamžité odvolání drží server. JWT není automaticky lepší volba.
API autorizace: Ověřený token může dodat identitu a scope, ale aplikace stále rozhoduje o konkrétním objektu a roli.

Výhody a omezení

Přenositelné claims za cenu jasné validační politiky.

Přínosy

kompaktní standardizovaná reprezentace claims
ověření přes veřejný klíč bez sdílení soukromého klíče
přirozená spolupráce oddělených API služeb
postupná rotace klíčů přes JWKS

Rizika

JWS payload není tajný a nesmí nést hesla ani citlivá data
dlouhá expirace zvyšuje dopad úniku a komplikuje odvolání
role uvnitř tokenu mohou zastarat
kontrola pouze podpisu bez iss a aud dovolí přijmout cizí token

Hranice použití

Volit podle bezpečnostního a provozního modelu.

Krátkodobý JWT je užitečný, když více služeb potřebuje ověřit důvěryhodné claims bez sdílené session databáze. Potřebuje však přísnou validaci, správu klíčů a plán pro zneplatnění přístupu. Krátká expirace snižuje dopad úniku, ale nezajistí okamžitou revokaci.

Klasická serverová session může být pro webovou aplikaci jednodušší a lépe ovladatelná. Do tokenu nepatří často se měnící data ani všechna oprávnění. Pro citlivou akci může aplikace požadovat aktuální kontrolu stavu nezávisle na obsahu tokenu.

Na co myslet

Tokeny zacházet jako s přístupovými údaji.

Kryptografii je vhodné svěřit prověřené knihovně, ne vlastnoručně psanému kódu.

allowlist očekávaných algoritmů a klíčů z důvěryhodného issueru
validace podpisu, iss, aud, exp a dalších povinných claims
krátká životnost, rotace klíčů a uvážený plán revokace
žádné tajné ani nadbytečné osobní údaje v podepsaném payloadu
bez logování tokenu, URL parametrů a celé identity payloadu

Časté otázky

Co je nutné skutečně ověřit

Je JWT šifrovaný?

Ne automaticky. Běžný JWS je podepsaný, ale čitelný. Důvěrnost poskytuje JWE nebo jiná vhodná ochrana.

Stačí JWT payload dekódovat?

Ne. Decode není verify. Před ověřením ochrany a claims je payload nedůvěryhodný vstup.

Co má API ověřit?

Očekávaný formát, pevně povolený algoritmus, kryptografickou ochranu, issuer, audience, platnost a claims potřebné pro daný typ tokenu.

Je JWT vhodný jako trvalá session?

Ne automaticky. Dlouhá platnost zvyšuje dopad úniku a komplikuje odvolání přístupu. Volba závisí na modelu aplikace.

Jak navrhuji API hranice v praxi

Tokeny posuzuji podle účelu, expirace a skutečných oprávnění.

U integračních API řeším bezpečnou autentizaci, omezený přístup, validaci a dohledatelnost provozních chyb.

Jak pracuji s API a integracemi Nezávazně probrat projekt