JWT exp/iat/nbf hibák: időigényes hibák, amelyek megtörik a hitelesítést

JWT időkövetelések -exp, iat, és nbf- megtévesztően egyszerűek. Ezek csak Unix időbélyegek. Mégis ezek okozzák a legelkeserítőbb hitelesítési hibákat a gyártás során: túl hamar lejáró tokenek, olyan tokenek, amelyek az egyik szerveren működnek, de a másikon nem, és olyan tokenek, amelyek soha nem járnak le.

Ez a cikk bemutatja a leggyakoribb időigénylési hibákat, azok előfordulásának okát és a biztonságos alapértelmezett beállításokkal történő kijavításukat.

Hogyan működik az exp, iat és nbf

Minden JWT három, időhöz kapcsolódó követelést hordozhat a rakományában:

• exp(Lejárati idő) — a tokent NEM SZABAD elfogadni ezen időbélyeg után
• iat(Kiadva) – amikor a token létrejött
• nbf(Nem előtte) – a tokent NEM SZABAD elfogadni ezen időbélyeg előtt

Mindhárom az numerikus dátumok: a másodpercek száma 1970-01-01T00:00:00Z (Unix korszak) óta. Nem ezredmásodpercek – másodpercek. Ez a megkülönböztetés önmagában okozza az összes JWT időhiba körülbelül 20%-át.

Használd a mi JWT dekóder hogy azonnal megvizsgálja az időigényeket bármely tokenben.

1. hiba: Ezredmásodpercek használata másodpercek helyett

JavaScript Dátum.most() ezredmásodpercet ad vissza. A JWT specifikációhoz másodpercek szükségesek. Beállítás exp hogy Dátum.most() + 3600000 létrehoz egy tokent, amely 2089-ben jár le, nem egy óra múlva.

// WRONG — ezredmásodperc
const exp = Dátum.most() + 3600000; // HELYES — másodperc
const exp = Math.floor(Dátum.most() / 1000) + 3600;

A legtöbb JWT-könyvtár ezt belsőleg kezeli, de ha manuálisan építi fel a hasznos adatokat, akkor ezt először ellenőrizni kell.

2. hiba: Hiányzó exp Claim Entirely

Ha elfelejtette beállítani exp, sok könyvtár boldogan létrehoz egy tokent, amely soha nem jár le. Ez biztonsági kockázatot jelent: a kiszivárgott token örökre érvényes marad.

Mindig állítsa be exp. Mindig érvényesítse a szerveren. Ha a könyvtára nem utasítja el a tokeneket anélkül exp alapértelmezés szerint konfigurálja úgy.

// Node.js jsonwebtoken — a lejárat kényszerítése
jwt.verify(token, titkos, { maxAge: '1h' });

3. hiba: Óracsúszás a szerverek között

Az A szerver 14:00:00-kor ad ki egy tokent. A B szerver órája 13:59:55-öt mutat (5 másodperces lemaradás). Ha a token rendelkezik nbf: 1711540800(14:00:00), B szerver elutasítja, mint "még nem érvényes".

Ez különösen gyakori a következőkben:

• Mikroszolgáltatási architektúrák nem szinkronizált órákkal
• Szerver nélküli funkciók, ahol a konténerek óraeltolódással rendelkeznek
• Mobilalkalmazások, ahol az eszköz órája manuálisan van beállítva

A Javítás

Engedjen meg egy kicsi óra tolerancia("leaway"-nek is nevezik) – általában 30–60 másodperc:

// jsonwebtoken
jwt.verify(token, secret, { clockTolerance: 30 }); // jose (Node.js)
await jwtVerify(token, kulcs, { clockTolerance: '30s' });

Soha ne állítson 2 percnél nagyobb tűréshatárt. Ha többre van szüksége, javítsa ki az NTP-szinkronizálást.

4. hiba: Rossz érvényesítési sorrend

A helyes érvényesítési sorrend számít. Ha a lejárat ellenőrzése után ellenőrzi az aláírást, a támadó jövőbeli tokent készíthet exp amely átmegy az időellenőrzésen, de érvénytelen az aláírása.

Biztonságos érvényesítési sorrend:

1. Fejléc dekódolása (ellenőrző algoritmus)
2. Az aláírás ellenőrzése
3. Ellenőrzés exp(elutasítás, ha lejárt)
4. Ellenőrzés nbf(elutasítás, ha még nem érvényes)
5. Ellenőrzés iat(elutasítom, ha indokolatlanul régi)
6. Ellenőrizze a kibocsátót, a közönséget és az egyéb követeléseket

A legtöbb jól karbantartott könyvtár ezt helyesen kezeli, de az egyéni köztes szoftver gyakran hibázik.

5. hiba: Időzóna-zavar az iat-ben

A JWT időbélyegek mindig UTC-k. De a fejlesztők néha helyi idő szerint hozzák létre őket:

// WRONG — helyi időzóna
const iat = new Date('2026-03-27T14:00:00').getTime() / 1000; // HELYES – explicit UTC
const iat = new Date('2026-03-27T14:00:00Z').getTime() / 1000;

Anélkül, hogy a Z utótag, a JavaScript értelmezi a karakterláncot a helyi időzónában, ami órákkal eltolja az időbélyeget.

6. hiba: Tokenek elfogadása nbf ellenőrzés nélkül

A nbf A követelés hasznos a késleltetett aktiválású tokeneknél – például egy olyan tokennél, amelynek csak ütemezett telepítés után kell működnie. Ha a validátor figyelmen kívül hagyja nbf, ezek a tokenek a tervezett aktiválási idő előtt felhasználhatók.

A legtöbb könyvtár érvényesíti nbf alapértelmezés szerint, de ellenőrizze ezt a telepítés során, különösen egyéni köztes szoftverrel.

7. hiba: Túl hosszú lejárat

Beállítás exp 30 napra, ha egy hozzáférési token legyőzi a rövid élettartamú tokenek célját. Bevált gyakorlatok:

• Hozzáférési tokenek: 5-15 perc
• Tokenek frissítése: 7-30 nap (rotációval)
• Azonosító tokenek: 1 óra

A biztonságos frissítési token mintákért tekintse meg a következő útmutatónkat JWT frissítési jogkivonat elforgatása.

Tesztesetek, amelyekkel minden API-nak rendelkeznie kell

Adja hozzá ezeket a tesztcsomaghoz, hogy korán észlelje az időigénylési hibákat:

1. Token with exp a múltban → 401
2. Token with exp pontosan most → 401 (határ)
3. Token számmal exp → 401
4. Token with nbf a jövőben → 401
5. Token with nbf kicsit a jövőben (a tűréshatáron belül) → 200
6. Token with iat a jövőben → 401 (hamisítást jelez)
7. Token ezredmásodperces időbélyegekkel → 401 (észleli az ms/s-os hibát)

Biztonságos alapértelmezések a népszerű keretrendszerekhez

Node.js (jsonwebtoken)

jwt.sign(payload, secret, { expiresIn: '15m' });
jwt.verify(token, titkos, { óra tolerancia: 30, maxAge: "15m"
});

Python (PyJWT)

jwt.decode(token, kulcs, algorithms=['HS256'], leeway=timedelta(másodperc=30), options={'require': ['exp', 'iat']})

Menj (golang-jwt)

értelmező := jwt.NewParser( jwt.WithLeeway(30 * time.Second), jwt.WithValidMethods([]string{"HS256"}),
)

Kapcsolódó eszközök és cikkek

• JWT dekóder— az időigényeket bármilyen jellel megvizsgálni
• JWT biztonsági hibák— a JWT tágabb buktatói az időigényen túl
• Token forgatás frissítése— biztonságos minta a hosszú élettartamú ülésekhez
• 2FA útmutató— a tokeneken túl egy második réteg hozzáadása