JWT がすぐに期限切れになる理由: exp はミリ秒ではなく秒単位です

10:00 に発行され、10:00 に期限切れ — トークンは最初の使用時に拒否され、サーバー クロックは問題ではありませんでした

最初のリクエストでトークンが拒否された場合、サーバー スキューの疑いが生じますが、クロックを変更する前に生のクレームを検査してください。あるコンポーネントがミリ秒クロックから `exp` を生成し、別のコンポーネントが NumericDate 秒を比較する場合、値は 3 桁異なります。通常の同期調整ではこのギャップを説明できません。

ベアラー トークンは資格情報であるため、使い捨てまたは編集されたトークンを使用します。 ToolAcre の JWT デコーダーはペイロード データを読み取りますが、意図的に署名を検証しません。元のテスト フィクスチャとその意図された有効期間を保存した後でのみ、数値の時間クレームをタイムスタンプ コンバータにコピーしてください。

RFC 7519 の内容 — 1970-01-01T00:00:00Z からの秒数としての NumericDate、およびそれが文字列ではなく数値である理由

隣接する公開済みの JWT 記事には、すでに重要な規約が記載されています: `exp` NumericDate は Unix エポックからの秒数をカウントします。その規格の説明を繰り返しても、ここでは何の価値もありません。実際的な問題は、各プロデューサー、シリアライザー、ベリファイアー、およびテスト フィクスチャが同じスケールを尊重するかどうかです。

明示的な境界コードを探します。発行時にはミリ秒クロックが秒に分割され、検証時には秒が比較されます。クレームは、算術に使用される書式設定された日付ではなく、数値のままにする必要があります。人間が判読できる UTC は診断投影であり、トークンの信頼できる表現ではありません。

発行者および検証者のテストでこのコントラクトをゼロ以外の値で固定します。エポック ゼロを使用したテストでは、どちらの側が 1,000 で除算されたのか、または 1,000 倍されたのかを明らかにすることはできません。

既存の JWT 記事では、NumericDate 秒が確立されています。この記事では、その事実を有効期限のデバッグに適用します。

検証者が有効な秒数の主張をミリ秒として解釈すると、日付は 1970 に近くなり、期限切れのように見えます。発行者が現在のミリ秒値を、後で秒として解釈されるフィールドに書き込むと、有効期限は意図された有効期間をはるかに超えたり、ライブラリのサポート範囲を超えたりします。どの症状が現れるかによって、どちらの側にスケール エラーがあるかがわかります。

桁数に基づいて両方の形式を受け入れる「修正」は避けてください。これにより、不正な形式のトークンが永続的な代替プロトコルに変わり、発行者の回帰を隠すことができます。アプリケーションの NumericDate コントラクトに違反する値を拒否し、生成を修正し、秒とミリ秒を区別するフィクスチャを追加します。

ミリ秒単位の間違いは、どちらの側が間違っているかに応じて、即座に拒否されたり、信じられないほど遠い期限切れになったりする可能性があります。

ペイロードをデコードして、フレームワークが変換する前に `exp`、`iat`、および `nbf` を生の値として公開します。 `exp − iat` を意図されたトークンの有効期間 (秒単位) と比較します。 `nbf` を個別に確認してください。トークンは有効期限が切れていないにもかかわらず使用できない場合があります。合理的に見える時代から信憑性を推測しないでください。

ToolAcre のデコーダーは、署名検証が false であると報告するため、その出力はデバッグに属し、承認には属しません。変更されたペイロードには、攻撃者が選択した任意の有効期限が含まれる可能性があります。信頼できるアプリケーション検証者は、元のコンパクト トークンに対してアルゴリズム、キー、発行者、対象者、および時間のポリシーを適用する必要があります。

有効な例: 1700003600 の exp — UTC および現地時間に変換し、iat と照合して、有効期間が意図したものであることを確認します。

`iat = 1,700,000,000` と `exp = 1,700,003,600` の場合、減算すると 3,600 秒、つまり 1 時間になります。コンバーターは有効期限を明示的に秒単位で読み取り、`2023-11-14T23:13:20.000Z` を返します。発行時刻は `2023-11-14T22:13:20.000Z` です。

これらの数値は、この記事の診断例に固有のものです。ミリ秒を選択すると 1 月の 1970 測定値が生成される場合、それはスケールが間違っている証拠であることが予想されます。 1 時間ポリシーが正しく実装されていると判断する前に、検証者の現在時刻も秒単位で表されていることを確認してください。

1 時間の差はフォーマット前に計算されるため、どのゾーンでも 1 時間のままになります。ローカルの表示は異なる場合がありますが、`exp − iat` は異なります。

有効な例: 明示的な秒数を使用して、exp 1,700,003,600 を近くの iat と比較します。

検証者は、わずかなクロックの違いに対応するために、時間クレームの周りに小さなアプリケーション定義の許容誤差を許可する場合があります。このリポジトリでは推奨秒数が定義されていないため、ここでは普遍的な余裕は規定されていません。セキュリティ ポリシーとライブラリ構成が権限を持ちます。

公差は 1,000 倍に比べて小さいままである必要があります。不正な請求が通過するまで拡張すると、有効期限の強制が弱まり、発行者のバグが生きたままになります。まず、クロック単位と同期を正規化します。次に、制限された許容量がアプリケーションの脅威モデルに役立つかどうかを決定します。

許容値が設定されている場合は、その境界の内側と外側の値を数秒でテストします。これにより、日付やロケールのレンダリングとは独立してポリシーが証明されます。

公差では 1,000 の係数の不一致を修復できません

タイムスタンプ変換では、トークンの署名、許可されたアルゴリズム、キー、発行者、または対象者を検証できません。完全にフォーマットされた、将来の `exp` クレームであっても、偽造トークン内に存在する可能性があります。 JWT デコーダーはこの境界に関して意図的に透過的であるため、信頼できる検証者と組み合わせる必要があります。

また、取得された実稼働トークンが取り消されているかどうか、またはセッション ポリシーがその名目上の有効期限をオーバーライドしているかどうかも確認できません。非機密フィクスチャを使用して値をデバッグします。実際のインシデントで認証情報を調べる必要がある場合は、一般的なクリップボード ワークフローではなく、承認された環境と処理手順を使用してください。

デコードは、ルーチンのデバッグ中に合成フィクスチャまたは安全に編集されたフィクスチャを使用してのみ行われます。ライブベアラー資格情報をコピーすると、タイムスタンプの計算とは関係のないセキュリティ上の問題が発生します。

要点: exp は 13 桁ではなく 10 桁です。また、JWT デコーダーと Unix タイムスタンプ コンバーターが同じタブに配置され、クレームを数秒で確認できる方法についても説明します。

JWT 時間クレームをすべての境界で秒として扱い、その差異を期間としてテストします。タイムスタンプ コンバーターは、個々のクレームを UTC およびローカル コンテキストに変換します。 JWT デコーダーは生の数値を公開します。彼らは一緒に、信頼を主張することなくタイミングについて説明します。

永続的な修正は、トークンが機能するまでユニットを切り替えるサポート Runbook ではなく、発行および検証コードに属します。明示的な秒数を保持し、不正な形式のスケールを拒否し、署名の検証を別個の必須の決定として保持します。

この分離により、可観測性も向上します。生成ログはトークンを公開せずに期間ポリシーを報告でき、検証メトリクスは期限切れ、時期尚早、無効な署名の結果を区別できます。