Unix-Timestamps bei JWT und Token-Ablauf — So funktioniert es

Wenn du jemals ein JWT dekodiert hast und etwas wie "exp": 1744070400 gesehen hast, bist du Unix-Timestamps in einer ihrer häufigsten praktischen Anwendungen begegnet. Das Ablauf-System für JSON Web Tokens basiert vollständig auf Unix-Zeit — und wenn du verstanden hast, wie es funktioniert, wird das Debuggen von Token-Problemen viel einfacher.

Der Unix Timestamp Converter wandelt jede rohe Timestamp-Zahl sofort in ein lesbares Datum um. Dieser Artikel behandelt, wie JWT-Claims Unix-Timestamps nutzen, wie du Ablauf-Zeiten berechnest und wo typischerweise Probleme entstehen.

Was exp und iat wirklich bedeuten

Eine dekodierte JWT-Payload sieht ungefähr so aus:

{
  "sub": "user_12345",
  "iat": 1743984000,
  "exp": 1744070400,
  "role": "admin"
}

Sowohl iat (issued at) als auch exp (expiry) sind Unix-Timestamps — die Anzahl der Sekunden seit dem 1. Januar 1970, 00:00:00 UTC. Sie haben nichts mit der lokalen Zeitzone deines Servers zu tun; sie basieren immer auf UTC.

iat: 1743984000 bedeutet, dass der Token zu dieser bestimmten Sekunde in der Geschichte ausgestellt wurde. exp: 1744070400 bedeutet, dass der Token ab dieser Sekunde ungültig wird. Der Unterschied zwischen ihnen — 86.400 Sekunden — ist die autorisierte Lebensdauer des Tokens. In diesem Fall genau 24 Stunden.

Um zu prüfen, welchem Datum diese Timestamps entsprechen, füge eine der beiden Zahlen in den Unix Timestamp Converter ein. 1743984000 entspricht dem 7. April 2026, 00:00:00 UTC. 1744070400 entspricht dem 8. April 2026, 00:00:00 UTC.

Wie die Token-Lebensdauer berechnet wird

Die Logik ist einfach. Wenn ein Server einen Token ausstellt, geschieht Folgendes:

1. Er ermittelt den aktuellen Unix-Timestamp (nennen wir ihn now) 2. Addiert die gewünschte Lebensdauer in Sekunden 3. Setzt die Summe als exp-Claim

Für einen 1-Stunden-Token: exp = now + 3600 Für einen 24-Stunden-Token: exp = now + 86400 Für einen 7-Tage-Token: exp = now + 604800 Für einen 30-Tage-Token: exp = now + 2592000

Wenn ein Client den Token vorlegt, prüft der Server, ob der aktuelle Timestamp kleiner als exp ist. Wenn current_time > exp, wird der Token als abgelaufen zurückgewiesen.

Die Berechnung ist reine Integer-Arithmetik — keine Zeitzonen-Umwandlungen, keine Kalender-Logik, keine Probleme mit unterschiedlichen Monatslängen. Das ist einer der Gründe, warum Unix-Timestamps dafür so gut funktionieren.

Übliche Token-Lebensdauern nach Anwendungsfall

Passwort-Reset- und E-Mail-Verifizierungs-Tokens sollten kurz sein — sie sind einmalig verwendbar und sensibel. Refresh-Tokens können länger sein, weil sie sicher gespeichert werden und serverseitig widerrufen werden können.

Debugging von Token-Ablauf-Problemen

Wenn ein Token unerwartet zurückgewiesen wird, ist der erste Schritt, ihn zu dekodieren und das exp-Feld zu prüfen. Die meisten JWT-Bibliotheken haben eine Dekodierungsfunktion, die die Signatur nicht verifiziert — nützlich zur Inspektion, wenn du nur die Claims lesen möchtest.

Sobald du den exp-Wert hast, füge ihn in den Unix Timestamp Converter ein, um die lesbare Ablauf-Zeit zu erhalten. Vergleiche das mit der aktuellen Zeit. Wenn der Token vor drei Stunden abgelaufen ist, weißt du, dass das Problem ein veralteter Token ist. Wenn der Ablauf in der Zukunft liegt und der Token immer noch zurückgewiesen wird, liegt das Problem woanders — Signatur-Fehler, falscher Audience-Claim oder ein Clock-Skew-Problem.

Clock Skew ist ein häufiges Problem in verteilten Systemen. Wenn der ausstellende Server und der validierende Server Uhren haben, die um mehr als ein paar Sekunden abweichen, können Tokens als abgelaufen zurückgewiesen werden, obwohl sie es nicht sollten, oder akzeptiert werden, obwohl sie abgelaufen sein sollten. Die meisten JWT-Bibliotheken erlauben deshalb eine kleine Clock-Skew-Toleranz — typischerweise 30 Sekunden bis 5 Minuten.

Der iat-Claim hilft hier. Wenn iat aus der Perspektive des validierenden Servers in der Zukunft liegt, ist die Uhr des ausstellenden Servers voraus. Wenn exp - iat nicht der erwarteten Token-Lebensdauer entspricht, ist etwas bei der Ausstellung schiefgelaufen.

Sekunden vs. Millisekunden: Ein häufiger JWT-Bug

Unix-Timestamps sind in Sekunden. Javascripts Date.now() gibt Millisekunden zurück. Diese Nichtübereinstimmung führt zu Bugs, die schwer zu erkennen sein können.

Wenn dein Node.js-Code das macht:

const exp = Date.now() + 3600; // Falsch: Date.now() ist in Millisekunden

Du hast einen Ablauf gesetzt, der etwa 1 Millisekunde in der Zukunft liegt (aktuelle Millisekunden + 3600 Millisekunden = im Grunde jetzt). Der Token wird sofort zurückgewiesen.

Die richtige Version:

const exp = Math.floor(Date.now() / 1000) + 3600; // Richtig: erst in Sekunden umwandeln

Eine 13-stellige Zahl in einem JWT-exp-Feld ist ein sicheres Zeichen, dass Millisekunden versehentlich verwendet wurden. Standard-Unix-Timestamps haben ab 2026 10 Ziffern. Wenn du exp: 1744070400000 siehst, entspricht dieser Timestamp dem Jahr 57.000-irgendwas — ein klares Signal, dass Millisekunden in ein Sekunden-Feld gelangt sind.

Der nbf-Claim: Not Before

JWT unterstützt auch einen nbf-Claim (not before), ebenfalls ein Unix-Timestamp. Er gibt die früheste Zeit an, zu der der Token gültig ist. Wenn current_time < nbf, wird der Token zurückgewiesen, auch wenn er nicht abgelaufen ist.

Das ist nützlich für Tokens, die erst in der Zukunft gültig werden — eine geplante Zugriffsberechtigung, einen zeitgesteuerten Download-Link oder einen Token, der vor einem geplanten Ereignis ausgestellt wird. Die Kombination von nbf und exp definiert ein präzises Gültigkeitsfenster.

Beispiel: `json { "nbf": 1744070400, "exp": 1744156800 } `

Dieser Token wird am 8. April 2026, 00:00:00 UTC gültig und läuft am 9. April 2026, 00:00:00 UTC ab — ein 24-Stunden-Fenster, das in der Zukunft beginnt.

Tokens vor Ablauf widerrufen

Eine Einschränkung des zustandslosen JWT-Designs ist, dass du einen Token nicht vor seiner exp-Zeit widerrufen kannst, ohne serverseitigen Zustand zu verwalten. Wenn sich ein Benutzer abmeldet oder ein Token kompromittiert ist, bleibt der Token technisch bis zu seinem Ablauf gültig — es sei denn, du implementierst eine Blacklist.

Häufige Ansätze:

• Kurzlebige Access-Tokens + Refresh-Tokens: Halte Access-Tokens kurz (15 Minuten), damit sie schnell ablaufen. Widerrufe Refresh-Tokens bei der Abmeldung. Der Access-Token läuft bald von selbst ab.
• Token-Blacklist: Speichere widerrufte Token-IDs (normalerweise der jti-Claim) serverseitig bis zum Ablauf ihres exp. Mehr Overhead, aber ermöglicht sofortigen Widerruf.
• Token-Rotation: Gib bei jeder Refresh-Anfrage einen neuen Access-Token aus und invalidiere den alten.

Der Unix-Timestamp in exp ist die äußere Grenze der Gültigkeit. Deine Anwendungslogik bestimmt, ob ein Token innerhalb dieses Fensters tatsächlich berücksichtigt werden sollte.

Token-Ablauf in der Praxis lesen

Wenn du eine API debuggst und schnell prüfen möchtest, ob ein Token abgelaufen ist, brauchst du keine vollständige JWT-Bibliothek. Dekodiere die Payload (das mittlere Segment des JWT) von Base64, parse das JSON und prüfe das exp-Feld gegen den aktuellen Unix-Timestamp.

In einer Browser-Konsole: `javascript const payload = JSON.parse(atob(token.split('.')[1])); console.log('Läuft ab:', new Date(payload.exp * 1000).toISOString()); console.log('Abgelaufen:', Date.now() / 1000 > payload.exp); `

Oder füge den exp-Wert einfach in den Unix Timestamp Converter ein, um das lesbare Datum zu erhalten, ohne Code zu schreiben. Das ist normalerweise der schnellste Weg, um beim Debugging in der Produktion die Frage „ist dieser Token abgelaufen?" zu beantworten.