Bez dobré dokumentace API se frontend a backend navzájem zablokují
Jak poznat, že jazyk zvládnete a nezaseknete
Synchronizace místo hromadění zm�
Kdy si dát pozor na kombinace a slučitelno
JWT (JSON Web Token) je kompaktní způsob, jak bezstavově ověřovat požadavky na API. Token se skládá ze tří částí oddělených tečkou: hlavičky, payloadu a podpisu. Hlavička určuje algoritmus (např. HS256 nebo RS256), payload nese tzv. claims – obvykle identifikátor uživatele, roli, čas expirace (exp) a případně další metadata. Podpis zajišťuje integritu: pokud se payload změní, podpis přestane platit. Server token při každém požadavku pouze ověří podpisem a zkontroluje expiraci, takže nepotřebuje ukládat session.
Ukládání tokenu na klientovi je častý zdroj problémů. Prohlížečová aplikace by měla přístupový token držet v paměti a obnovovat ho pomocí refresh tokenu v HttpOnly cookie s atributy Secure a SameSite. Vyhněte se localStorage – je zranitelný vůči XSS. U mobilních aplikací použijte bezpečné úložiště (Keychain, Keystore). Při odhlášení nebo změně hesla nezapomeňte invalidovat refresh token na serveru, i když přístupový token still platí do své expirace.
Kód aplikace a její konfigurace mají odlišný životní cyklus, jinak se mění a jinak se nasazují. Kód prochází code review, testy a vydává se ve verzích. Konfigurace se mění podle prostředí, tajných klíčů a provozních potřeb, často bez jakékoli souvislosti s vydáním. Když obojí leží v jednom repozitáři, každá změna konfigurace znečistí historii kódu a každý commit do kódu nutí ověřovat, zda nezměnil i konfiguraci. Oddělení není dogma, ale řeší konkrétní problémy, které dřív nebo později narazí.
Nejčastější důvod, proč se spolupráce frontendu a backendu zadrhne, není technický dluh ani špatná architektura. Je to dokumentace, která buď chybí, nebo popisuje něco jiného, než API skutečně dělá. Výsledkem jsou dohady v chatu, zbytečné přepisování kódu a zpoždění, které nikdo neplánoval. Dokumentace přitom není administrativa navíc – je to nástroj, který určuje, kdo co může dělat a kdy.
Doba platnosti tokenu má být krátká – řádově minuty až hodiny. Pro delší sezení používejte refresh token, který je uložen bezpečně (HttpOnly cookie, nikoli localStorage) a lze ho jednorázově zneplatnit. Claims jako role nebo oprávnění neberte jako absolutní pravdu, pokud se mohou změnit během platnosti tokenu. Buď je ověřujte proti databázi, nebo zvolte kratší expiraci. Do payloadu nikdy nedávejte citlivé údaje (hesla, rodná čísla, čísla karet) – payload je pouze podepsaný, ne šifrovaný, takže si ho kdokoli přečte.
Mezi typické chyby patří: absence kontroly exp, nbf a iss, příliš dlouhá platnost, podepisování slabým klíčem, ukládání tokenu do URL (dostane se do logů) a chybějící revokace. Dále opomenutí omezení počtu požadavků na obnovení tokenu nebo nezvládnuté souběžné obnovy. Testujte scénáře, kdy token vyprší, je podepsán jiným klíčem nebo obsahuje pozměněné claims. Bezpečnost stojí na správné konfiguraci knihovny, krátké expiraci a obezřetném zacházení s klíči i s úložištěm na klientovi.
Podepisování a ověřování Pro symetrické podepisování (HS256) používejte dostatečně dlouhý a náhodný klíč, ideálně z proměnné prostředí, nikdy ne v kódu. Asymetrické algoritmy (RS256, ES256) jsou vhodné, když token vydává jedna služba a ověřuje jiná – veřejný klíč lze bezpečně distribuovat. Vždy explicitně povolte pouze jeden algoritmus a při ověřování ho vynuťte. Typická chyba je přijetí algoritmu none nebo toho, který útočník vloží do hlavičky. Totéž platí pro ignorování podpisu u knihoven, které to umožňují konfigurací.