Warum Ihr JWT sofort abläuft: exp ist in Sekunden, nicht in Millisekunden

Ausgestellt um 10:00, abgelaufen um 10:00 – ein Token, der bei seiner ersten Verwendung abgelehnt wurde, und eine Serveruhr, die nicht das Problem war

Ein Token, der bei seiner ersten Anfrage abgelehnt wird, lässt den Verdacht auf einen Serverversatz aufkommen. Überprüfen Sie jedoch die Rohansprüche, bevor Sie die Uhren umstellen. Wenn eine Komponente `exp` aus einem Millisekundentakt generiert, während eine andere NumericDate-Sekunden vergleicht, unterscheiden sich die Werte um drei Größenordnungen. Keine gewöhnliche Synchronisierungsanpassung erklärt diese Lücke.

Verwenden Sie ein wegwerfbares oder redigiertes Token, da es sich bei einem Inhabertoken um einen Berechtigungsnachweis handelt. Der JWT-Decoder von ToolAcre liest Nutzdaten, überprüft aber bewusst keine Signaturen. Kopieren Sie den numerischen Zeitanspruch erst in den Zeitstempelkonverter, nachdem Sie das ursprüngliche Testgerät und seine vorgesehene Lebensdauer erhalten haben.

Was RFC 7519 sagt – NumericDate als Sekunden seit 1970-01-01T00:00:00Z und warum es sich eher um eine Zahl als um eine Zeichenfolge handelt

Der nebenstehende veröffentlichte JWT-Artikel nennt bereits den entscheidenden Vertrag: `exp` NumericDate zählt Sekunden ab der Unix-Epoche. Eine Wiederholung der Standarderklärung würde hier keinen Mehrwert bringen. Die praktische Frage ist, ob jeder Hersteller, Serialisierer, Verifizierer und Testgerät denselben Maßstab einhält.

Suchen Sie nach einem expliziten Grenzcode: einer Millisekundenuhr, die bei der Ausgabe in Sekunden unterteilt ist, und einem Sekundenvergleich bei der Validierung. Der Anspruch sollte eine Zahl bleiben und kein formatiertes Datum, das für die Arithmetik verwendet wird. Die für Menschen lesbare UTC ist eine diagnostische Projektion und nicht die maßgebliche Darstellung des Tokens.

Pinnen Sie diesen Vertrag in Aussteller- und Verifizierertests mit einem Wert ungleich Null. Ein Test mit Epoche Null kann nicht aufdecken, ob eine Seite mit Tausend geteilt oder multipliziert wird.

Der vorhandene Artikel JWT legt NumericDate-Sekunden fest; Dieser Artikel wendet diese Tatsache auf das Ablauf-Debugging an

Wenn ein Prüfer einen gültigen Sekundenanspruch als Millisekunden interpretiert, liegt das Datum in der Nähe von 1970 und scheint abgelaufen zu sein. Wenn ein Aussteller einen aktuellen Millisekundenwert in ein Feld schreibt, das später als Sekunden interpretiert wird, verschiebt sich der Ablauf weit über die vorgesehene Lebensdauer oder den von einer Bibliothek unterstützten Bereich hinaus. Welches Symptom auftritt, gibt an, auf welcher Seite der Skalenfehler liegt.

Vermeiden Sie einen „Fix“, der beide Formen basierend auf der Ziffernanzahl akzeptiert. Dadurch werden fehlerhafte Token zu einem dauerhaften Alternativprotokoll und können Regressionen des Emittenten verbergen. Lehnen Sie Werte ab, die gegen den NumericDate-Vertrag der Anwendung verstoßen, korrigieren Sie die Generierung und fügen Sie Vorrichtungen hinzu, die Sekunden von Millisekunden unterscheiden.

Millisekundenfehler können zu einer sofortigen Ablehnung oder einem unplausiblen Fernablauf führen, je nachdem, welche Seite falsch liegt

Dekodieren Sie die Nutzlast, um `exp`, `iat` und `nbf` als Rohwerte verfügbar zu machen, bevor ein Framework sie konvertiert. Vergleichen Sie `exp − iat` mit der beabsichtigten Token-Lebensdauer in Sekunden. Überprüfen Sie `nbf` separat; Ein Token kann nicht abgelaufen, aber nicht verwendbar sein. Schließen Sie nicht aus vernünftig aussehenden Zeiten auf Authentizität.

Der Decoder von ToolAcre meldet, dass die Signaturüberprüfung falsch ist, daher gehört seine Ausgabe zum Debuggen und niemals zur Autorisierung. Eine modifizierte Nutzlast kann ein beliebiges Ablaufdatum enthalten, das ein Angreifer wählt. Der vertrauenswürdige Anwendungsverifizierer muss weiterhin Algorithmus, Schlüssel, Aussteller, Zielgruppe und Zeitrichtlinien für das ursprüngliche kompakte Token durchsetzen.

Funktioniertes Beispiel: ein exp von 1700003600 – es in UTC und Ortszeit umzuwandeln, es mit iat zu vergleichen und die Lebensdauer zu bestätigen, ist das, was Sie beabsichtigt haben

Für `iat = 1,700,000,000` und `exp = 1,700,003,600` ergibt die Subtraktion 3,600 Sekunden oder eine Stunde. Der Konverter liest den Ablauf explizit als Sekunden und gibt `2023-11-14T23:13:20.000Z` zurück; Die Ausgabezeit ist `2023-11-14T22:13:20.000Z`.

Diese Zahlen gelten nur für das Diagnosebeispiel dieses Artikels. Wenn die Auswahl von Millisekunden einen Messwert vom Januar 1970 ergibt, ist dies ein erwarteter Hinweis auf die falsche Skala. Stellen Sie sicher, dass die aktuelle Zeit des Prüfers ebenfalls in Sekunden angegeben ist, bevor Sie zu dem Schluss kommen, dass die einstündige Richtlinie korrekt implementiert ist.

Die Differenz von einer Stunde wird vor der Formatierung berechnet, sodass sie in jeder Zone eine Stunde beträgt. Lokale Anzeigen können abweichen, `exp − iat` jedoch nicht.

Funktioniertes Beispiel: Vergleichen Sie exp 1,700,003,600 mit einem nahegelegenen iat unter Verwendung expliziter Sekunden

Ein Verifizierer kann eine kleine, von der Anwendung definierte Toleranz für Zeitansprüche zulassen, um geringfügige Zeitunterschiede auszugleichen. Dieses Repository definiert keine empfohlene Anzahl an Sekunden, sodass hier kein allgemeingültiger Spielraum vorgeschrieben ist. Die Sicherheitsrichtlinie und die Bibliothekskonfiguration sind die Autoritäten.

Die Toleranz sollte im Verhältnis zum Faktor Tausend winzig bleiben. Eine Ausweitung, bis ein fehlerhafter Anspruch bestanden wird, schwächt die Durchsetzung des Ablaufdatums und lässt den Issuer-Bug bestehen. Normalisieren Sie zunächst die Takteinheiten und die Synchronisation. Entscheiden Sie dann, ob eine begrenzte Menge dem Bedrohungsmodell der Anwendung dient.

Wenn eine Toleranz konfiguriert ist, testen Sie Werte innerhalb und außerhalb dieser Grenze in Sekunden. Dies beweist die Richtlinie unabhängig von der Datums- oder Gebietsschemadarstellung.

Toleranz kann eine Nichtübereinstimmung des Faktors 1,000 nicht reparieren

Die Zeitstempelkonvertierung kann die Signatur, den zulässigen Algorithmus, den Schlüssel, den Aussteller oder die Zielgruppe eines Tokens nicht überprüfen. Sogar ein perfekt formatierter, zukünftiger `exp`-Anspruch kann in einem gefälschten Token enthalten sein. Der JWT-Decoder ist in Bezug auf diese Grenze absichtlich transparent und sollte mit einem vertrauenswürdigen Verifizierer gekoppelt werden.

Es kann auch nicht festgestellt werden, ob ein erfasstes Produktionstoken widerrufen wurde oder ob eine Sitzungsrichtlinie seinen nominellen Ablauf überschreibt. Debuggen Sie Werte mit nicht sensiblen Fixtures. Wenn ein echter Vorfall die Prüfung von Anmeldeinformationen erfordert, verwenden Sie die autorisierte Umgebung und das Bearbeitungsverfahren anstelle eines allgemeinen Arbeitsablaufs in der Zwischenablage.

Die Dekodierung sollte nur mit synthetischen oder sicher redigierten Fixtures während des routinemäßigen Debuggens erfolgen. Das Kopieren eines Live-Bearer-Berechtigungsnachweises führt zu einem Sicherheitsproblem, das nichts mit der Zeitstempelarithmetik zu tun hat.

Takeaway: exp besteht aus zehn Ziffern, nicht aus dreizehn – und wie sich der JWT-Decoder und der Unix-Zeitstempelkonverter in derselben Registerkarte befinden, sodass Sie einen Anspruch in Sekundenschnelle überprüfen können

Behandeln Sie JWT Zeitansprüche als Sekunden an jeder Grenze und testen Sie ihre Unterschiede als Dauern. Der Zeitstempelkonverter wandelt einen einzelnen Anspruch in UTC und einen lokalen Kontext um; Der JWT-Decoder stellt die Rohzahl bereit. Gemeinsam erklären sie das Timing, ohne Vertrauen zu beanspruchen.

Die dauerhafte Korrektur gehört in den Ausstellungs- und Verifizierungscode, nicht in ein Support-Runbook, das Einheiten umschaltet, bis ein Token funktioniert. Behalten Sie explizite Sekunden bei, lehnen Sie fehlerhafte Skalen ab und behalten Sie die Signaturüberprüfung als separate verbindliche Entscheidung bei.

Diese Trennung verbessert auch die Beobachtbarkeit: Generierungsprotokolle können eine Dauerrichtlinie melden, ohne Token offenzulegen, während Verifizierungsmetriken abgelaufene, vorzeitige und Ergebnisse mit ungültiger Signatur unterscheiden können.