Perché il tuo JWT scade immediatamente: l'exp è espressa in secondi, non in millisecondi

Emesso alle 10:00, scaduto alle 10:00: un token rifiutato al primo utilizzo e un orologio del server che non era il problema

Un token rifiutato alla sua prima richiesta fa sospettare un disallineamento del server, ma controlla le affermazioni grezze prima di cambiare gli orologi. Se un componente genera `exp` da un orologio in millisecondi mentre un altro confronta i secondi di NumericDate, i valori differiscono di tre ordini di grandezza. Nessun aggiustamento ordinario della sincronizzazione spiega questo divario.

Utilizza un token usa e getta o redatto perché un token al portatore è una credenziale. Il decoder JWT di ToolAcre legge i dati del carico utile ma deliberatamente non verifica le firme. Copiare la dichiarazione di tempo numerico nel convertitore di timestamp solo dopo aver preservato il dispositivo di prova originale e la sua durata prevista.

Cosa dice RFC 7519 — NumericDate in secondi da 1970-01-01T00:00:00Z e perché è un numero anziché una stringa

L'articolo JWT pubblicato adiacente afferma già il contratto cruciale: `exp` NumericDate conta i secondi dall'epoca Unix. Ripetere la spiegazione degli standard non aggiungerebbe alcun valore qui. La questione pratica è se ogni produttore, serializzatore, verificatore e apparecchio di prova rispetti la stessa scala.

Cerca un codice limite esplicito: un orologio in millisecondi diviso in secondi durante l'emissione e un confronto dei secondi durante la convalida. L'attestazione dovrebbe rimanere un numero anziché una data formattata utilizzata per l'aritmetica. UTC leggibile dall'uomo è una proiezione diagnostica, non la rappresentazione autorevole del token.

Blocca questo contratto nei test dell'emittente e del verificatore con un valore diverso da zero. Un test che utilizza l'epoca zero non può rivelare se uno dei due lati è stato diviso o moltiplicato per mille.

L'articolo JWT esistente stabilisce i secondi NumericDate; in questo articolo si applica questo fatto al debug della scadenza

Se un verificatore interpreta una richiesta di secondi valida come millisecondi, la data si avvicina a 1970 e appare scaduta. Se un emittente scrive un valore corrente in millisecondi in un campo successivamente interpretato come secondi, la scadenza si sposta ben oltre la durata prevista o oltre l’intervallo supportato da una libreria. Il sintomo visualizzato identifica quale lato possiede l'errore di scala.

Evitare una "correzione" che accetti entrambe le forme in base al conteggio delle cifre. Ciò trasforma i token malformati in un protocollo alternativo permanente e può nascondere le regressioni dell'emittente. Rifiuta i valori che violano il contratto NumericDate dell'applicazione, correggi la generazione e aggiungi dispositivi che distinguono i secondi dai millisecondi.

Errori di millisecondi possono creare un rifiuto immediato o una scadenza implausibilmente remota a seconda di quale parte ha torto

Decodifica il payload per esporre `exp`, `iat` e `nbf` come valori grezzi prima che un framework li converta. Confronta `exp − iat` con la durata prevista del token in secondi. Controlla `nbf` separatamente; un token può essere scaduto ma non utilizzabile. Non dedurre l'autenticità da tempi apparentemente ragionevoli.

Il decodificatore di ToolAcre segnala che la verifica della firma è falsa, quindi il suo output appartiene al debug, mai all'autorizzazione. Un payload modificato può contenere qualsiasi scadenza scelta dall'attaccante. Il verificatore dell'applicazione attendibile deve comunque applicare l'algoritmo, la chiave, l'emittente, il pubblico e la policy temporale sul token compatto originale.

Esempio funzionante: un'exp di 1700003600: convertila in UTC e ora locale, confrontala con iat e conferma che la durata è ciò che volevi

Per `iat = 1,700,000,000` e `exp = 1,700,003,600`, la sottrazione restituisce 3,600 secondi o un'ora. Il convertitore legge la scadenza esplicitamente come secondi e restituisce `2023-11-14T23:13:20.000Z`; l'ora di emissione è `2023-11-14T22:13:20.000Z`.

Questi numeri sono unici per l’esempio diagnostico di questo articolo. Se la selezione dei millisecondi produce una lettura di gennaio 1970, è probabile che si tratti di una scala errata. Confermare che anche l'ora corrente del verificatore sia espressa in secondi prima di concludere che la politica di un'ora sia implementata correttamente.

La differenza di un'ora viene calcolata prima della formattazione, quindi rimane un'ora in ogni zona. Le visualizzazioni locali possono differire, ma `exp − iat` no.

Esempio realizzato: confronta exp 1,700,003,600 con uno iat vicino utilizzando secondi espliciti

Un verificatore può consentire una piccola tolleranza definita dall'applicazione in merito alle dichiarazioni temporali per accogliere modeste differenze di orologio. Questo repository non definisce un numero di secondi consigliato, quindi qui non viene prescritto alcun margine universale. Le autorità sono la politica di sicurezza e la configurazione della libreria.

La tolleranza dovrebbe rimanere piccola rispetto a un fattore mille. Espanderlo finché non passa una richiesta non valida indebolisce l'applicazione della scadenza e lascia vivo il bug dell'emittente. Per prima cosa normalizzare le unità dell'orologio e la sincronizzazione; quindi decidere se un’indennità limitata rientra nel modello di minaccia dell’applicazione.

Se è configurata una tolleranza, testa i valori appena all'interno e all'esterno di tale limite in pochi secondi. Ciò dimostra la politica indipendentemente da qualsiasi data o rendering locale.

La tolleranza non può riparare una mancata corrispondenza del fattore 1,000

La conversione del timestamp non può verificare la firma di un token, l'algoritmo consentito, la chiave, l'emittente o il pubblico. Anche una futura richiesta `exp` perfettamente formattata potrebbe trovarsi all'interno di un token contraffatto. Il decodificatore JWT è intenzionalmente trasparente riguardo a questo limite e deve essere associato a un verificatore attendibile.

Inoltre, non è in grado di stabilire se un token di produzione catturato sia stato revocato o se una policy di sessione ne prevalga la scadenza nominale. Valori di debug con dispositivi non sensibili. Se un incidente reale richiede l'esame delle credenziali, utilizzare l'ambiente autorizzato e la procedura di gestione anziché un flusso di lavoro generale degli appunti.

La decodifica dovrebbe avvenire solo con dispositivi sintetici o revisionati in modo sicuro durante il debug di routine. La copia di una credenziale al portatore attiva crea un problema di sicurezza non correlato all'aritmetica del timestamp.

In conclusione: l'exp è composta da dieci cifre, non tredici, e come il decodificatore JWT e il convertitore di timestamp Unix si trovano nella stessa scheda in modo da poter verificare un reclamo in pochi secondi

Tratta le dichiarazioni di tempo JWT come secondi ad ogni confine e verifica le loro differenze come durate. Il convertitore di timestamp trasforma una singola rivendicazione in UTC e nel contesto locale; il decoder JWT espone il numero grezzo. Insieme spiegano i tempi senza rivendicare fiducia.

La correzione duratura appartiene al codice di emissione e verifica, non a un runbook di supporto che alterna le unità finché un token non funziona. Conserva i secondi espliciti, rifiuta la scala con formato errato e mantieni la verifica della firma come decisione obbligatoria separata.

Questa separazione migliora anche l’osservabilità: i log di generazione possono riportare una politica di durata senza esporre i token, mentre i parametri di verifica possono distinguere i risultati scaduti, prematuri e con firma non valida.