Útočník zvyčajne nemusí prelomiť podpisový algoritmus. Stačí, že aplikácia claims iba dekóduje, prijme nesprávny kľúč, ignoruje audience alebo nechá dlhodobo platný bearer token uniknúť do logu. JWT je malý formát obklopený veľkým autentizačným systémom. Kľúče, expiracia, revokácia, browser storage a autorizácia rozhodujú rovnako ako samotná kryptografia.

Dekódovanie nie je validácia

Header a payload možno prečítať bez kľúča. Útočník si vytvorí vlastný token s ľubovoľným user ID alebo rolou. Kým úspešne neprejde podpis a všetky povinné claims, každá hodnota je nedôveryhodný vstup.

Authorization logic sa spúšťa až po kompletnej validácii. Čiastočne overený objekt sa neposúva ďalším vrstvám.

Token nesmie vyberať bezpečnostnú politiku

Header uvádza algoritmus, no verifier ho porovná s allowlistom pre konkrétneho issuera. Historické zraniteľnosti vznikli pri prijatí unsigned tokenu alebo zámene symetrického a asymetrického režimu.

kid je nedôveryhodná hodnota. Môže vybrať iba kľúč z kontrolovanej kolekcie, nie súbor, SQL fragment alebo vzdialenú adresu.

Audience a issuer sú rovnako dôležité ako podpis

Token môže byť správne podpísaný známou organizáciou a stále určený inému produktu. Bez audience checku ho služba prijme mimo zamýšľaného kontextu. Issuer sa porovnáva s presnou očakávanou hodnotou.

V multi-tenant systéme musí tenant claim súhlasiť s routou, účtom a objektom. Podpísaná hodnota sama nevytvára oprávnenie ku každému tenantovi.

Časové claims potrebujú malú a zdokumentovanú toleranciu

Expiration a not-before sa kontrolujú voči dôveryhodným hodinám. Malý clock skew môže kompenzovať rozdiel uzlov, no veľká tolerancia predlžuje život ukradnutého tokenu. Jednotka a zaokrúhlenie musia byť konzistentné.

Testy overujú presnú hranicu expirácie, token z budúcnosti aj zlé hodiny. Ignorovať chybu času pri probléme synchronizácie je nebezpečný fallback.

Dlhý access token robí revokáciu pomalou

Po odchode zamestnanca alebo zmene hesla môže samostatný token fungovať až do exp. Centrálna revocation kontrola to rieši, ale vracia shared state do každej služby.

Bežný model používa krátke access tokeny a rotované refresh tokeny. Pri podozrivej udalosti sa zruší refresh rodina a podľa rizika aj aktuálne sessions.

Payload nemá niesť tajomstvá ani celý profil

Podpísaný JWT je čitateľný. Heslá, privátne kľúče a dôverné údaje doň nepatria. Aj bežný e-mail či roly sa kopírujú do klientov, logov a služieb s rozdielnou retenciou.

Minimalistické claims znižujú privacy riziko, request size aj zastarávanie. Premenlivé detaily sa načítajú z autoritatívneho zdroja.

Browser storage nemá univerzálnu odpoveď

Token dostupný JavaScriptu je ohrozený pri XSS. HttpOnly cookie obmedzí čítanie skriptom, ale aplikácia musí riešiť CSRF a SameSite. JWT v cookie je stále cookie credential.

Voľba vychádza z domén, klienta a threat modelu. Žiadne úložisko nezachráni aplikáciu s nebezpečnými DOM sinks alebo širokou third-party skriptovou dôverou.

Podpísaná rola nenahrádza objektovú autorizáciu

Claim editor neznamená právo upraviť každý dokument. Aplikácia musí overiť vlastníctvo, tenant, stav objektu a konkrétnu operáciu proti aktuálnym doménovým dátam.

JWT validation vytvára dôveryhodný identity context. Finálne rozhodnutie patrí policy vrstve a má samostatné testy.

Key rotation sa navrhuje pred incidentom

Privátny kľúč môže uniknúť a bežne sa obnovuje. Služby potrebujú cache verejných kľúčov, prekryv počas rotácie a spôsob rýchleho vyradenia kompromitovaného ID.

Pravidelný nácvik ukáže stale cache, služby s hardcoded key a monitoring, ktorý nevie rozlíšiť neznámy key od neplatného podpisu.

Kompromitácia podpisového kľúča mení všetky tokeny

Ak unikne privátny kľúč, útočník môže vytvárať nové tokeny s ľubovoľnými claims. Nestačí čakať na expiráciu existujúcich hodnôt. Vydavateľ musí kľúč vyradiť, publikovať náhradu a všetky služby musia prestať starému ID dôverovať.

Incidentný plán určí, či treba odhlásiť používateľov, zrušiť refresh tokeny a analyzovať issuance logs. Dlhé cache TTL alebo offline verifier bez aktualizačnej cesty predĺžia kompromitáciu. Key ID, algoritmus a čas validácie sa zaznamenávajú bez uloženia celého bearer tokenu.

Replay ochrana závisí od použitia tokenu

Platný podpis nezabráni opakovanému odoslaniu rovnakého requestu. Pri jednorazovej finančnej alebo administratívnej operácii je potrebný idempotency key, nonce alebo serverový záznam použitia. Access token iba určuje identity context.

Veľmi krátke časové okno znižuje riziko, ale nenahrádza idempotenciu. Business operácia musí bezpečne rozlíšiť retry po timeoute od druhého nezávislého príkazu.

Testujú sa najmä rejection paths

Sada musí odmietnuť zmenený payload, wrong audience, cudzí issuer, expired token, nepovolený algoritmus, neznámy key a malformed segmenty. Nestačí jeden úspešný login.

Produkčné metriky rozlišujú bežnú expiráciu od prudkého nárastu invalid signatures. Alert nesmie obsahovať credential, iba bezpečný kontext služby a pravidla.

Prísnosť je vlastnosť, nie nepríjemnosť

Bezpečný verifier presne vie, kto smie vydávať tokeny, ktoré algoritmy a kľúče prijíma, kde sa token používa a dokedy platí. Všetko ostatné odmietne, aj keď sa dá bez chyby dekódovať.

Centralizovaná knižnica pomáha udržať pravidlá, každá služba však musí dokazovať aktuálnu konfiguráciu. Starý benevolentný verifier nesmie zostať trvalou kompatibilnou zadnou cestou.

Odstránenie výnimky sa sleduje rovnakou metrikou ako jej zavedenie.

Pravidelný audit porovná povolené algoritmy, issuer, audience, clock skew a spôsob načítania kľúčov vo všetkých deployoch. Rozdiel medzi prostrediami môže znamenať, že token odmietnutý v hlavnom API stále funguje v menej viditeľnom internom endpoint-e. Bezpečnostná politika má byť verzovaná, distribuovaná automaticky a sledovaná metrikou. Výnimka potrebuje konkrétny dôvod, vlastníka a dátum ďalšieho prehodnotenia.

Výsledok kontroly patrí do bezpečnostného auditu služby.