JWT exp/iat/nbf-Fehler: Time-Claim-Fehler, die die Authentifizierung unterbrechen

JWT-Zeitansprüche – exp, iat und nbf – sind täuschend einfach. Es sind lediglich Unix-Zeitstempel. Dennoch verursachen sie einige der frustrierendsten Authentifizierungsfehler in der Produktion: Token, die zu früh ablaufen, Token, die auf einem Server funktionieren, auf einem anderen jedoch nicht, und Token, die überhaupt nie ablaufen.

Dieser Artikel behandelt die häufigsten Fehler bei Zeitansprüchen, warum sie auftreten und wie man sie mit sicheren Standardeinstellungen behebt.

Wie exp, iat und nbf funktionieren

Jedes JWT kann drei zeitbezogene Ansprüche in seiner Nutzlast enthalten:

• exp (Ablaufzeit) – das Token DARF nach diesem Zeitstempel NICHT akzeptiert werden
• iat (Ausgestellt am) – wann das Token erstellt wurde
• nbf (Nicht vorher) – das Token DARF NICHT vor diesem Zeitstempel akzeptiert werden

Alle drei sind numerische Daten: die Anzahl der Sekunden seit 1970-01-01T00:00:00Z (Unix-Epoche). Nicht Millisekunden – Sekunden. Allein diese Unterscheidung verursacht etwa 20 % aller JWT-Zeitfehler.

Verwenden Sie unseren JWT-Decoder, um Zeitansprüche in jedem Token sofort zu überprüfen.

Bug Nr. 1: Verwendung von Millisekunden statt Sekunden

JavaScripts Date.now() gibt Millisekunden zurück. Die JWT-Spezifikation erfordert Sekunden. Wenn Sie exp auf Date.now() + 3600000 setzen, wird ein Token erstellt, das im Jahr 2089 und nicht in einer Stunde abläuft.

// FALSCH – Millisekunden
const exp = Date.now() + 3600000; // RICHTIG – Sekunden
const exp = Math.floor(Date.now() / 1000) + 3600;

Die meisten JWT-Bibliotheken handhaben dies intern, aber wenn Sie Payloads manuell erstellen, ist dies das Erste, was Sie überprüfen müssen.

Fehler Nr. 2: Exp-Anspruch fehlt vollständig

Wenn Sie vergessen, exp festzulegen, erstellen viele Bibliotheken problemlos ein Token, das nie abläuft. Dies stellt ein Sicherheitsrisiko dar: Ein durchgesickertes Token bleibt für immer gültig.

Immer exp festlegen. Validieren Sie es immer auf dem Server. Wenn Ihre Bibliothek Token ohne exp nicht standardmäßig ablehnt, konfigurieren Sie sie entsprechend.

// Node.js jsonwebtoken – Ablauf erzwingen
jwt.verify(token, Secret, { maxAge: '1h' });

Fehler Nr. 3: Taktversatz zwischen Servern

Server A gibt um 14:00:00 Uhr einen Token aus. Die Uhr von Server B zeigt 13:59:55 (5 Sekunden später). Wenn der Token nbf: 1711540800 (14:00:00) hat, lehnt Server B ihn als „noch nicht gültig“ ab.

Dies kommt besonders häufig vor in:

• Microservice-Architekturen mit unsynchronisierten Uhren
• Serverlose Funktionen, bei denen Container eine Taktabweichung aufweisen
• Mobile Apps, bei denen die Geräteuhr manuell eingestellt wird

Die Lösung

Erlauben Sie eine kleine Uhrtoleranz (auch „Spielraum“ genannt) – normalerweise 30–60 Sekunden:

// jsonwebtoken
jwt.verify(token, Secret, { clockTolerance: 30 }); // jose (Node.js)
Warten auf jwtVerify(token, key, { clockTolerance: '30s' });

Stellen Sie die Toleranz niemals auf mehr als 2 Minuten ein. Wenn Sie mehr benötigen, korrigieren Sie stattdessen Ihre NTP-Synchronisierung.

Fehler Nr. 4: Falsche Validierungsreihenfolge

Die richtige Validierungsreihenfolge ist wichtig. Wenn Sie die Signatur nach der Überprüfung des Ablaufs überprüfen, kann ein Angreifer ein Token mit einem zukünftigen exp erstellen, das die Zeitprüfung besteht, aber eine ungültige Signatur aufweist.

Sichere Validierungsreihenfolge:

1. Header dekodieren (Algorithmus prüfen)
2. Signatur überprüfen
3. Überprüfen Sie exp (ablehnen, wenn abgelaufen)
4. Überprüfen Sie nbf (ablehnen, wenn noch nicht gültig)
5. Überprüfen Sie iat (ablehnen Sie ab, wenn es unangemessen alt ist)
6. Emittenten, Zielgruppe und andere Ansprüche prüfen

Die meisten gut gewarteten Bibliotheken handhaben dies korrekt, aber benutzerdefinierte Middleware macht es oft falsch.

Fehler Nr. 5: Zeitzonenverwirrung in iat

JWT-Zeitstempel sind immer UTC. Aber Entwickler erstellen sie manchmal unter Verwendung der Ortszeit:

// FALSCH – lokale Zeitzone
const iat = new Date('2026-03-27T14:00:00').getTime() / 1000; // RICHTIG – explizite UTC
const iat = new Date('2026-03-27T14:00:00Z').getTime() / 1000;

Ohne das Suffix Z interpretiert JavaScript die Zeichenfolge in der lokalen Zeitzone, wodurch der Zeitstempel um Stunden verschoben werden kann.

Fehler Nr. 6: Akzeptieren von Token ohne NBF-Prüfung

Der Anspruch nbf ist nützlich für Token mit verzögerter Aktivierung – beispielsweise ein Token, das nur nach einer geplanten Bereitstellung funktionieren sollte. Wenn Ihr Validator nbf ignoriert, können diese Token vor ihrem vorgesehenen Aktivierungszeitpunkt verwendet werden.

Die meisten Bibliotheken validieren standardmäßig nbf, aber überprüfen Sie dies in Ihrem Setup, insbesondere mit benutzerdefinierter Middleware.

Fehler Nr. 7: Zu langes Ablaufdatum

Das Festlegen von exp auf 30 Tage für ein Zugriffstoken macht den Zweck kurzlebiger Token zunichte. Best Practices:

• Zugriffstokens: 5–15 Minuten
• Tokens aktualisieren: 7–30 Tage (mit Rotation)
• ID-Tokens: 1 Stunde

Informationen zu sicheren Aktualisierungstokenmustern finden Sie in unserem Leitfaden zu JWT-Aktualisierungstokenrotation.

Testfälle, die jede API haben sollte

Fügen Sie diese zu Ihrer Testsuite hinzu, um Fehler bei der Zeitanforderung frühzeitig zu erkennen:

1. Token mit exp in der Vergangenheit → 401
2. Token mit exp genau jetzt → 401 (Grenze)
3. Token ohne exp → 401
4. Token mit nbf in der Zukunft → 401
5. Token mit nbf leicht in der Zukunft (innerhalb der Toleranz) → 200
6. Token mit iat in der Zukunft → 401 (weist auf Manipulation hin)
7. Token mit Millisekunden-Zeitstempeln → 401 (erkennt den ms/s-Fehler)

Sichere Standardeinstellungen für beliebte Frameworks

Node.js (jsonwebtoken)

jwt.sign(Nutzlast, Geheimnis, { expiresIn: '15m' });
jwt.verify(token, Secret, { clockTolerance: 30, maxAge: '15m'
});

Python (PyJWT)

jwt.decode(token, key, algorithms=['HS256'], Spielraum=Zeitdelta(Sekunden=30), Optionen={'require': ['exp', 'iat']})

Go (golang-jwt)

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

Verwandte Tools und Artikel

• JWT Decoder – Zeitansprüche in jedem Token prüfen
• JWT-Sicherheitsfehler – umfassendere JWT-Fallstricke über Zeitansprüche hinaus
• Tokenrotation aktualisieren – sicheres Muster für langlebige Sitzungen
• 2FA-Anleitung – Fügen Sie eine zweite Ebene über die Token hinaus hinzu