開發者工具·Unix時間戳轉換器
為什麼您的 JWT 立即過期：exp 以秒為單位，而不是毫秒
· 為什麼它很重要
jwt 時間戳 安全
RFC 7519 將 exp、iat 和 nbf 定義為自紀元以來的秒數，並將其與毫秒時鐘混合使令牌立即過期或永不過期。這篇文章解釋了宣告格式以及如何檢查令牌的時間。
於 10:00 發布，於 10:00 過期 — 令牌在首次使用時被拒絕，伺服器時鐘不是問題
第一次請求被拒絕的令牌會引起對伺服器偏差的懷疑，但在更改時脈之前檢查原始宣告。如果一個元件從毫秒時鐘產生 `exp`，而另一個元件則比較 NumericDate 秒，則這些值相差三個數量級。普通的同步調整無法解釋這種差距。
使用一次性或經過編輯的令牌，因為不記名令牌是一種憑證。 ToolAcre 的 JWT 解碼器讀取有效負載資料，但故意不驗證簽章。僅在保留原始測試夾具及其預期壽命後，才將數位時間宣告複製到時間戳記轉換器中。
RFC 7519 所說的 — NumericDate 自 1970-01-01T00:00:00Z 以來的秒數，以及為什麼它是數字而不是字符串
相鄰發表的 JWT 文章已經說明了關鍵合約： `exp` NumericDate 從 Unix 紀元開始計算秒數。重複其標準解釋在這裡不會增加任何價值。實際問題是每個生產者、序列化器、驗證器和測試裝置是否遵循相同的規模。
尋找明確邊界代碼：發佈時將毫秒時脈分成秒，驗證時進行秒比較。宣告應保留為數字，而不是用於算術的格式化日期。人類可讀的 UTC 是一種診斷預測，而不是令牌的權威表示。
在發行者和驗證者測試中將此合約固定為非零值。使用零紀元的測試無法揭示任何一方是否除或乘以一千。
現有的 JWT 文章建立 NumericDate 秒；本文將此事實應用於過期調試
如果驗證者將有效的秒宣告解釋為毫秒，則日期接近 1970 並顯示為過期。如果發行者將目前毫秒值寫入稍後解釋為秒的欄位中，則到期時間將遠遠超出預期生命週期或超出庫支援的範圍。出現哪一種症狀可以確定哪一方有比例誤差。
避免根據數字計數接受兩種形式的「修復」。這會將格式錯誤的代幣變成永久的替代協議，並可以隱藏發行者的回歸。拒絕違反應用程式 NumericDate 約定的值，正確產生，並添加區分秒和毫秒的固定裝置。
毫秒錯誤可能會導致立即拒絕或令人難以置信的遠端過期，具體取決於哪一方出錯
在框架轉換之前解碼有效負載以將 `exp`、`iat` 和 `nbf` 作為原始值公開。將 `exp − iat` 與預期令牌生命週期（以秒為單位）進行比較。單獨檢查`nbf`；令牌可能未過期但無法使用。不要從看似合理的時間推斷真實性。
ToolAcre 的解碼器報告簽章驗證錯誤，因此其輸出屬於偵錯，而不是授權。修改後的有效負載可以包含攻擊者選擇的任何到期時間。可信任應用程式驗證者仍必須對原始緊湊令牌執行演演算法、金鑰、發行者、受眾和時間策略。
工作範例：1700003600 的 exp — 將其轉換為 UTC 和本地時間，根據 iat 檢查它，並確認生命週期是您想要的
對於 `iat = 1,700,000,000` 和 `exp = 1,700,003,600`，相減得到 3,600 秒，即一小時。轉換器將到期時間明確讀取為秒並傳回 `2023-11-14T23:13:20.000Z`；發佈時間為 `2023-11-14T22:13:20.000Z`。
這些數字對於本文的診斷範例來說是唯一的。如果選擇毫秒會產生 1 月 1970 讀數，則表示比例錯誤。在得出一小時政策正確實施的結論之前，請確認驗證者的當前時間也以秒為單位表示。
一小時的差異是在格式化之前計算的，因此每個區域仍保持一小時。本機顯示可能有所不同，但 `exp − iat` 不會。
工作範例：使用明確秒數將 exp 1,700,003,600 與附近的 iat 進行比較
驗證者可能允許應用程式定義的時間宣告的較小容差，以適應適度的時脈差異。此儲存庫沒有定義建議的秒數，因此這裡沒有規定通用的迴旋餘地。安全性策略和庫配置才是權威。
相對於千倍，公差應該保持很小。將其擴展直至格式錯誤的索賠通過會削弱到期執行並導致發行人錯誤繼續存在。首先標準化時鐘單元和同步；然後決定有限限額是否服務於應用程式的威脅模型。
如果配置了容差，則在幾秒鐘內測試該邊界內部和外部的值。這證明了策略獨立於任何日期或區域設定呈現。
容差無法修正 1,000 因子的不匹配
時間戳轉換無法驗證令牌的簽章、允許的演演算法、金鑰、發行者或受眾。即使是格式完美的未來 `exp` 宣告也可能位於偽造的令牌內。 JWT 解碼器有意對此邊界透明，並應與可信任驗證器配對。
它也無法決定捕獲的生產令牌是否已被撤銷，或會話策略是否覆寫其名義到期時間。使用非敏感裝置調試值。如果真實事件需要檢查憑證，請使用授權環境和處理程序，而不是一般的剪貼簿工作流程。
在例行調試期間，應僅使用合成或安全編輯的裝置進行解碼。複製即時持有者憑證會產生與時間戳演演算法無關的安全性問題。
重點：exp 是十位數字，而不是十三位 — 以及 JWT 解碼器和 Unix 時間戳轉換器如何位於同一個分頁中，以便您可以在幾秒鐘內檢查索賠
將 JWT 時間宣告視為每個邊界處的秒數，並測試它們的差異作為持續時間。時間戳轉換器將單一宣告轉換為 UTC 和本機上下文； JWT 解碼器公開原始數字。他們一起解釋時機，但沒有聲稱信任。
持久更正屬於發布和驗證代碼，而不是在令牌起作用之前切換單位的支援運作手冊。保留明確的秒數，拒絕格式錯誤的比例，並將簽章驗證保留為單獨的強制決策。
這種分離也提高了可觀察性：產生日誌可以在不暴露令牌的情況下報告持續時間策略，而驗證指標可以區分過期、過早和無效簽章結果。