JWT-Ablauf und Ausstellungszeitpunkt: Wie Unix-Timestamps die Token-Authentifizierung antreiben

Jedes Mal, wenn sich ein Nutzer in einer SaaS-Anwendung anmeldet, wird ein Auth-Token generiert und an den Browser oder die mobile App übermittelt. Dieses Token trägt eine unsichtbare Uhr in sich. Das JWT-Ablaufdatum, gespeichert als einfacher Unix-Timestamp, teilt jedem Server, der das Token liest, genau mit, ab wann die Anmeldedaten nicht mehr vertrauenswürdig sind. Schon wenige Sekunden Abweichung bei diesem Timestamp können dazu führen, dass Nutzer zu früh ausgesperrt werden - oder schlimmer, dass eine gültige Sitzung weit länger aktiv bleibt, als die Sicherheitsrichtlinie erlaubt. Zu verstehen, wie JSON Web Token Claims funktionieren - insbesondere exp und iat - ist eine der praktischsten Maßnahmen, die ein SaaS-Team ergreifen kann, um die Authentifizierung zu stärken, ohne die Nutzererfahrung zu verschlechtern.

Was ist ein JWT und warum enthält er Timestamps?

Ein JSON Web Token ist ein kompaktes, URL-sicheres Credential, das aus drei Base64-kodierten Teilen besteht, die durch Punkte getrennt sind: einem Header, einem Payload und einer Signatur. Im Payload befinden sich die zeitkritischen Daten. Da JWTs zustandslos sind, schlägt der Server keine Sitzung in einer Datenbank nach, um sie zu validieren. Stattdessen liest er die im Payload eingebetteten Claims und vertraut der kryptografischen Signatur. Dieses Konzept ist schnell und skalierbar, bringt aber eine wichtige Einschränkung mit sich: Ein einmal ausgestelltes Token kann vom Server nicht "gelöscht" werden. Die einzige zuverlässige Möglichkeit, seine Gültigkeit zu begrenzen, besteht darin, einen Ablauf-Timestamp direkt im Token zu hinterlegen.

Deshalb ist Zeit - konkret die Unix-Epoch-Zeit - so zentral für die JWT-Sicherheit. Die RFC 7519-Spezifikation, die JWTs definiert, schreibt vor, dass zeitbezogene Claims als sogenannte "NumericDate"-Werte ausgedrückt werden - also als Anzahl der Sekunden seit dem 1. Januar 1970 UTC. Keine Zeitzonen, keine lokale Formatierung - nur ein Integer, den jeder Server weltweit mit seiner eigenen Uhr vergleichen kann.

Die Claims exp und iat erklärt

Die JWT-Spezifikation definiert mehrere registrierte Claims. Für das Token-Lifecycle-Management sind zwei besonders relevant:

• exp (Ablaufzeitpunkt): Der Timestamp, nach dem das Token nicht mehr akzeptiert werden darf. Server sind verpflichtet, jedes Token abzulehnen, bei dem die aktuelle Zeit gleich oder größer als dieser Wert ist. Das ist der Kernmechanismus hinter der JWT-Ablaufsteuerung.
• iat (Ausstellungszeitpunkt): Der Timestamp, zu dem das Token erstellt wurde. Der iat Claim wird standardmäßig nicht erzwungen, ist aber äußerst nützlich: Er ermöglicht es, das Alter eines Tokens zu berechnen, eine maximale Gültigkeitsdauer unabhängig von exp durchzusetzen und Tokens zu erkennen, die verdächtig weit in der Vergangenheit ausgestellt wurden.

Ein dritter Claim, nbf (Not Before), definiert den frühesten Zeitpunkt, ab dem ein Token gültig ist. Er wird seltener verwendet, folgt aber demselben Unix-Timestamp-Format.

Alle drei Werte sind Integer. Werden sie in Millisekunden generiert - ein häufiger Fehler beim Einsatz von JavaScripts Date.now() - ist der resultierende Wert etwa 1.000-mal größer als erwartet. Ein Server, der exp mit der aktuellen Epoch-Sekunde vergleicht, sieht ein Token, das scheinbar im Jahr 33.658 abläuft, und wird es niemals ablehnen. Dieser Produktionsfehler hat bereits mehrere SaaS-Teams getroffen.

Ein konkretes Beispiel: Echte Token-Timestamps dekodieren

Angenommen, dein Authentifizierungsservice stellt nach einer Nutzeranmeldung um 10:00 Uhr UTC am 1. Juli 2025 folgenden JWT-Payload aus:

{
  "sub": "user_8821",
  "iat": 1751364000,
  "exp": 1751367600,
  "role": "admin"
}

Was bedeuten diese Zahlen konkret?

Die Differenz beträgt exakt 3.600 Sekunden, also eine Stunde. Jeder Server, der dieses Token nach 11:00:00 UTC empfängt, muss es ablehnen. Zur manuellen Überprüfung subtrahiert man iat von exp : 1751367600 - 1751364000 = 3600 Sekunden. Den menschenlesbaren Wert eines beliebigen Timestamps lässt sich sofort mit einem Unix-Timestamp-Konverter überprüfen - genau die Art schneller Plausibilitätsprüfung, die den oben genannten Millisekunden-Fehler verhindert.

Mehr zum Thema, wie Datenbanken diese Werte speichern sollten, findest du in unserem Leitfaden zu Unix-Timestamps in Datenbanken - das gleiche Integer-Format gilt sowohl für exp in einem Token als auch für Einträge in einer Audit-Log-Tabelle.

Clock Skew: Der stille Token-Killer

Hier ist eine Einschränkung, die Teams oft unvorbereitet trifft. In einem verteilten System sind Authentifizierungsserver und API-Server zwei verschiedene Maschinen. Ihre Systemuhren werden per NTP synchronisiert, sind aber nie perfekt aufeinander abgestimmt. Eine Abweichung von 30 bis 90 Sekunden ist in Cloud-Umgebungen durchaus üblich.

Stell dir folgendes Szenario vor: Ein Token mit exp = 1751367600 wird von einem API-Server validiert, dessen Uhr 1751367610 anzeigt - also nur 10 Sekunden nach dem Ablaufzeitpunkt. Das Token wird abgelehnt. Der Nutzer erhält einen 401-Fehler. Aus seiner Perspektive war er gerade angemeldet, und die App hat plötzlich nicht mehr funktioniert.

Die Standardlösung besteht darin, eine Clock-Skew-Toleranz in die Validierungslogik einzubauen. Die meisten JWT-Bibliotheken unterstützen einen Leeway-Parameter. Ein Wert von 60 Sekunden ist weithin akzeptiert und wird in der OpenID Connect Core-Spezifikation referenziert. Diesen Wert einzustellen, zu dokumentieren und sicherzustellen, dass alle Dienste im Stack denselben Wert verwenden, ist essenziell.

Den richtigen Token-Ablaufzeitraum für dein SaaS-Produkt wählen

Der optimale Token-Ablaufzeitraum hängt von der Sensitivität der Anwendung und dem erwarteten Sitzungsverhalten ab. Hier ist ein praxisnahes Framework:

• Hochsensible Anwendungen (Banking, Gesundheitswesen, Admin-Dashboards): 15 bis 30 Minuten für Access-Tokens. Refresh-Tokens verwenden, um Sitzungen automatisch zu erneuern.
• Standard-SaaS-Anwendungen (Projektmanagement, CRM, Analyse): 1 bis 8 Stunden. An die typische Arbeitssitzungsdauer anpassen.
• Risikoarme oder nur-lesende APIs: Bis zu 24 Stunden, aber kombiniert mit Token-Rotation bei sensiblen Aktionen.
• Machine-to-Machine Service-Tokens: Können länger gültig sein (Tage oder Wochen), sollten aber eng begrenzt und nach einem festen Zeitplan rotiert werden.

Eine nützliche Formel zur Berechnung des exp -Werts zum Ausstellungszeitpunkt:

// Node.js Beispiel
const iat = Math.floor(Date.now() / 1000); // aktuelle Zeit in Sekunden
const ttl = 3600; // Time-to-Live: 1 Stunde in Sekunden
const exp = iat + ttl;

const payload = {
  sub: userId,
  iat: iat,
  exp: exp
};

Die explizite Division durch 1000 konvertiert Millisekunden in Sekunden. Diese eine Zeile verhindert den häufigsten JWT-Timestamp-Fehler in JavaScript-Anwendungen.

Konkrete Schritte zur sicheren JWT-Ablaufkonfiguration

Hier ist eine konkrete Checkliste, die sich auf jedes SaaS-Authentifizierungssystem anwenden lässt:

1. Immer sowohl iat als auch exp einbinden. Der iat Claim ist technisch optional, liefert aber einen Audit-Trail und ermöglicht die Durchsetzung einer maximalen Token-Lebensdauer unabhängig vom Ablaufzeitpunkt.
2. Das Timestamp-Format vor dem Deployment prüfen. Das Token dekodieren und sicherstellen, dass exp ein 10-stelliger Integer ist. Ein 13-stelliger Wert bedeutet, dass Millisekunden eingeschlichen haben.
3. Einen Clock-Skew-Leeway von 60 Sekunden setzen in der Validierungs-Middleware. Diesen Wert einheitlich in allen Diensten anwenden, die Auth-Tokens verarbeiten.
4. Kurzlebige Access-Tokens mit Refresh-Tokens kombinieren. Ein 15-minütiger Access-Token kombiniert mit einem 7-tägigen Refresh-Token ist deutlich sicherer als ein einzelner 7-tägiger Access-Token, da der Refresh-Token serverseitig widerrufen werden kann.
5. Den iat -Wert bei jeder authentifizierten Anfrage protokollieren. So lassen sich Anomalien erkennen - zum Beispiel, wenn dasselbe Token gleichzeitig aus zwei verschiedenen geografischen Regionen verwendet wird.
6. Den Ablauf in der Staging-Umgebung mit beschleunigter Zeit testen. Die Uhr so mocken, dass sie über den exp -Wert hinausspringt, und sicherstellen, dass die App den 401-Fehler sauber behandelt - ohne Absturz oder Endlosschleife.

Wenn du einen rohen exp -Wert aus einem Token schnell in ein lesbares Datum umwandeln oder prüfen möchtest, welchen Timestamp du für eine bestimmte Dauer setzen solltest, erledigt der Epoch-Konverter auf unserer Startseite beide Richtungen sofort - ganz ohne Code.

Fazit

Die JWT-Ablaufsteuerung ist kein komplexes Konzept, aber eines, bei dem kleine Fehler große Sicherheitslücken erzeugen. Die Claims exp und iat sind schlicht Integer - Unix-Timestamps in Sekunden ab der Epoch. Diese Einfachheit ist ihre Stärke: Jeder Server, jede Programmiersprache und jede Plattform kann zwei Zahlen eindeutig miteinander vergleichen. Die eigentliche Herausforderung liegt in der korrekten Anwendung: einen sinnvollen Token-Ablaufzeitraum wählen, Clock Skew mit einem Toleranzfenster abfangen und den Millisekunden-Fehler erkennen, bevor er in Produktion gelangt. Wer diese Praktiken in die Auth-Pipeline integriert, erhält eine JSON Web Token -Implementierung, die sowohl sicher als auch langfristig wartbar ist.

JWT-Timestamps sofort prüfen - ganz ohne Code

Füge einen beliebigen Unix-Timestamp aus einem JWT-Payload ein und wandle ihn mit einem Klick in ein lesbares Datum um. Millisekunden-Fehler erkennen, bevor sie in Produktion gelangen.

Kostenloses Tool ausprobieren →