JWT exp/iat/nbf chyby: chyby časových claimů, které lámou autorizaci

Časové nároky JWT —zk, iat a nbf— jsou klamně jednoduché. Jsou to jen časová razítka Unixu. Přesto způsobují některé z nejvíce frustrujících autentizačních chyb v produkci: tokeny, jejichž platnost vyprší příliš brzy, tokeny, které fungují na jednom serveru, ale ne na jiném, a tokeny, jejichž platnost nikdy nevyprší.

Tento článek pojednává o nejběžnějších chybách s časovým nárokováním, proč k nim dochází a jak je opravit pomocí bezpečných výchozích nastavení.

Jak fungují exp, iat a nbf

Každý JWT může ve svém užitečném zatížení nést tři nároky související s časem:

• zk(Doba platnosti) — token NESMÍ být přijat po tomto časovém razítku
• iat(Vydáno v) — kdy byl vytvořen token
• nbf(Ne dříve) — token NESMÍ být přijat před tímto časovým razítkem

Všechny tři jsou číselná data: počet sekund od roku 1970-01-01T00:00:00Z (epocha Unixu). Ne milisekundy – sekundy. Toto rozlišení samo o sobě způsobuje zhruba 20 % všech časových chyb JWT.

Použijte naše Dekodér JWT k okamžité kontrole časových nároků v jakémkoli tokenu.

Chyba č. 1: Používání milisekund místo sekund

JavaScript Date.now() vrátí milisekundy. Specifikace JWT vyžaduje sekund. Nastavení zk na Date.now() + 3600000 vytvoří token, jehož platnost vyprší v roce 2089, nikoli za jednu hodinu.

// ŠPATNĚ — milisekundy
const exp = Date.now() + 3600000; // SPRÁVNĚ — sekund
const exp = Math.floor(Date.now() / 1000) + 3600;

Většina knihoven JWT to řeší interně, ale pokud sestavujete užitečné zatížení ručně, je to první věc, kterou je třeba zkontrolovat.

Chyba č. 2: Úplný chybějící nárok na expedici

Pokud zapomenete nastavit zk, mnoho knihoven s radostí vytvoří token, který nikdy nevyprší. Jedná se o bezpečnostní riziko: uniklý token zůstává platný navždy.

Vždy nastaveno zk. Vždy to ověřte na serveru. Pokud vaše knihovna neodmítne tokeny bez zk ve výchozím nastavení jej k tomu nakonfigurujte.

// Node.js jsonwebtoken — vynutit vypršení platnosti
jwt.verify(token, tajné, { maxVěk: '1h' });

Chyba č. 3: Časový posun mezi servery

Server A vydá token ve 14:00:00. Hodiny serveru B ukazují 13:59:55 (5 sekund pozadu). Pokud má token nbf: 1711540800(14:00:00), server B jej odmítne jako „zatím neplatné“.

To je běžné zejména v:

• Architektury mikroslužeb s nesynchronizovanými hodinami
• Funkce bez serveru, kde kontejnery mají časový posun
• Mobilní aplikace, kde se hodiny zařízení nastavují ručně

Oprava

Povolit malý tolerance hodin(také nazývané „leeway“) – obvykle 30–60 sekund:

// jsonwebtoken
jwt.verify(token, secret, { clockTolerance: 30 }); // jose (Node.js)
wait jwtVerify(token, klíč, { clockTolerance: '30s' });

Nikdy nenastavujte toleranci nad 2 minuty. Pokud potřebujete více, opravte si synchronizaci NTP.

Chyba č. 4: Nesprávný příkaz k ověření

Na správném pořadí ověření záleží. Pokud po kontrole vypršení platnosti zkontrolujete podpis, útočník může vytvořit token s budoucností zk který prošel časovou kontrolou, ale má neplatný podpis.

Bezpečná validační objednávka:

1. Dekódovat záhlaví (kontrolní algoritmus)
2. Ověřte podpis
3. Kontrola zk(odmítnout, pokud vypršela platnost)
4. Kontrola nbf(odmítnout, pokud ještě není platné)
5. Kontrola iat(odmítnout, pokud je nepřiměřeně starý)
6. Zkontrolujte vydavatele, publikum a další nároky

Většina dobře udržovaných knihoven to řeší správně, ale vlastní middleware to často dělá špatně.

Chyba č. 5: Zmatek v časovém pásmu v IAT

Časová razítka JWT jsou vždy UTC. Ale vývojáři je někdy vytvářejí pomocí místního času:

// WRONG — místní časové pásmo
const iat = new Date('2026-03-27T14:00:00').getTime() / 1000; // CORRECT — explicitní UTC
const iat = new Date('2026-03-27T14:00:00Z').getTime() / 1000;

Bez Z přípona, JavaScript interpretuje řetězec v místním časovém pásmu, což může posunout časové razítko o hodiny.

Chyba č. 6: Přijímání tokenů bez kontroly nbf

The nbf claim je užitečný pro tokeny se zpožděnou aktivací – například token, který by měl fungovat až po plánovaném nasazení. Pokud váš validátor ignoruje nbf, lze tyto tokeny použít před zamýšlenou dobou aktivace.

Většina knihoven ověřuje nbf ve výchozím nastavení, ale ověřte si to ve svém nastavení, zejména s vlastním middlewarem.

Chyba č. 7: Příliš dlouhá doba platnosti

Nastavení zk na 30 dní, pokud přístupový token porušuje účel tokenů s krátkou životností. Doporučené postupy:

• Přístupové tokeny: 5–15 minut
• Obnovit tokeny: 7–30 dní (s rotací)
• ID tokeny: 1 hodina

Vzory tokenů pro bezpečné obnovení naleznete v našem průvodci Rotace obnovovacího tokenu JWT.

Testovací případy, které by mělo mít každé API

Přidejte tyto do své testovací sady, abyste včas zachytili chyby při nárokování času:

1. Token s zk v minulosti → 401
2. Token s zk přesně teď → 401 (hranice)
3. Token s č zk → 401
4. Token s nbf v budoucnu → 401
5. Token s nbf mírně v budoucnu (v rámci tolerance) → 200
6. Token s iat v budoucnu → 401 (označuje manipulaci)
7. Token s milisekundovými časovými razítky → 401 (detekuje chybu ms/s)

Bezpečná výchozí nastavení pro populární rámce

Node.js (jsonwebtoken)

jwt.sign(payload, secret, { expiresIn: '15m' });
jwt.verify(token, tajné, { Tolerance hodin: 30, maxVěk: '15m'
});

Python (PyJWT)

jwt.decode(token, klíč, algoritmy=['HS256'], leeway=timedelta(sekundy=30), options={'require': ['exp', 'iat']})

Jdi (golang-jwt)

analyzátor := jwt.NewParser( jwt.WithLeeway(30 *krát.Sekunda), jwt.WithValidMethods([]string{"HS256"}),
)

Související nástroje a články

• Dekodér JWT— zkontrolovat časové nároky v jakémkoli tokenu
• Bezpečnostní chyby JWT— Širší úskalí JWT za časovými nároky
• Obnovit rotaci tokenu— bezpečný vzor pro dlouhotrvající relace
• Průvodce 2FA— přidat druhou vrstvu za žetony