本文へスキップ
grsytools.jp

提出前・共有前の実務チェック

JWT期限チェッカー

JWTまたはexp値から有効期限を確認し、期限切れ・nbf前・残り時間を判定します。秒とミリ秒の桁違い、iatの未来時刻、0〜300秒のclock skewも確認できますが、汎用デコードと署名検証は行いません。

ページ更新日:

このページはJWTの有効期限(exp)を最初に確認したいときの入口です。
401/403の一次切り分けで「期限切れかどうか」を短時間で把握できます。claim全体(iss / aud / scopeなど)を詳しく確認したい場合はJWTデコーダーへ進んでください。

このページで先に確認すること

  1. expが現在時刻より未来か過去か。
  2. 残り時間が運用上の許容範囲か。
  3. 端末時刻のずれが判定に影響していないか。

ツール本体

入力・操作・結果

上から入力し、必要な操作を行って、表示された結果と次の操作を確認してください。

exp・nbf・iatと端末の現在時刻だけを比較します。署名、発行元、改ざんの有無は判定しません。

JWTのNumericDateは秒指定が標準です。13桁相当の値はミリ秒入力の可能性として検出し、確認用に秒へ換算します。

入力データは原則ブラウザ内で処理し、URLやアクセス解析へ保存しません。ページを更新すると入力は失われます。機密情報は入力しないでください。

使い方

  1. JWT(Bearer付き可)またはexpの数値を入力します。
  2. 「期限を判定」を押して、expの判定結果を確認します。
  3. JSTとUTCの時刻を見比べ、利用環境の基準時刻と照合します。

判定結果の表示例

  • 有効なトークン: 「有効」「残り時間: あと◯時間」のように表示されます。
  • 期限切れトークン: 「期限切れ」「◯分前に期限切れ」のように表示されます。

よくある失敗

  • expの時刻だけ見て、端末時計のずれを考慮せず誤判定する。
  • 期限判定だけで安心し、署名検証が未実施な点を見落とす。
  • ログ調査中のトークンをそのまま共有チャネルへ貼ってしまう。

利用場面の例

  • API 401発生時に、受信トークンのexpを見て期限切れ起因かを切り分ける。
  • ステージング環境で短期トークンを発行し、更新タイミングの挙動を確認する。

境界条件

  • expが未設定または数値以外のJWTは期限判定の対象外です。
  • NumericDateは秒指定が標準です。13桁相当の値はミリ秒入力の可能性として検出し、確認用に秒へ換算するため、発行側が標準外の値を設定していないか確認してください。

入出力例

  • 入力: exp が現在時刻より 3600 秒先のJWT → 出力: 「有効(残り約1時間)」
  • 入力: exp が現在時刻より 120 秒前のJWT → 出力: 「期限切れ(約2分経過)」

判断基準

期限起因の不具合切り分けでは、まずexpの前後関係を確認し、次に端末時計のずれ有無を確認します。最後に署名検証が別工程で実施されているかを合わせて確認すると、判定を誤りにくくなります。

向いてる人 / 向いてない人

向いてる人

  • 認証エラー時に期限要因を素早く確認したい人
  • デバッグ時にexpの残り時間を把握したい人

向いてない人

  • 署名検証や鍵検証までこの画面だけで完結したい人
  • 本番運用で機密トークンを頻繁に貼り付ける運用をしたい人

claim全体を確認したいときは「JWTデコーダー」を併用し、exp値そのものの読み替えには「UNIX時刻変換」が便利です。タイムゾーン差分の確認は「JST・UTC変換」で行うと、運用時の時刻認識ずれを減らせます。

検証・デバッグ・運用の注意

このページはexpの確認を素早く行うための補助用途です。検証では期限切れの切り分け、デバッグでは時刻表示の確認に有効ですが、運用判断では必ずサーバー側の認証結果と合わせて確認してください。

期限判定は端末時刻を基準にするため、端末時計がずれていると結果もずれます。

サンプルは動作確認用のダミー文字列です。実運用トークンの貼り付けは必要最小限にしてください。

このツールを使う場面

確認できること
JWTまたはexp値を読み取り、期限切れ、nbf前、残り時間、時刻ずれを確認できます。13桁相当の値はミリ秒入力の可能性として検出し、確認用に秒へ換算します。
使う前に見るポイント
NumericDateは秒指定が標準です。確認対象のJWTにexpが含まれているか、環境や時刻の基準をそろえておきます。
結果を見たあとにやること
期限が近い場合は更新処理や設定値を見直し、claim全体はJWTデコーダーで確認します。

作業全体に戻る場合は、近い課題別ページを開いてください。

開発でID・エンコード・ハッシュを扱う前の確認手順

ID、エンコード済み文字列、ハッシュ値は見た目が似ていても役割が違います。作るのか、戻すのか、照合するのかを先に決めます。

失敗しやすい確認例

  • expだけ見て署名検証を省略する

    期限が有効でもトークン自体が正当とは限りません。

    例: 判断ポイント: 判定後に署名検証系処理へ必ず進む

  • 端末時計のずれを無視する

    クライアント時刻ずれで期限判定が前後することがあります。

    例: 入力例: 期限直前トークン / 出力: 端末時計次第で有効/無効が揺れる

境界値・例外ケース

  • expが秒でなくミリ秒値になっている

    JWTのNumericDateは秒指定が標準です。このツールでは13桁相当の値をミリ秒入力の可能性として検出し、確認用に秒へ換算します。

    例: 判断ポイント: 発行側が標準外の値を設定していないか確認する

  • Bearer前置詞つき入力

    前置詞を含む文字列でもトークン部分を抽出して判定します。

    例: 入力例: Bearer eyJ... / 出力: exp判定実行

よくあるミス

  • JST表示だけで障害時刻を照合する

    認証基盤ログがUTC基準だと比較誤差が発生します。

    例: 運用例: 先にUTCで照合し、必要に応じてJST変換

  • 判定結果を共有せず再調査を繰り返す

    同じ切り分けを複数人で繰り返す要因になります。

    例: 判断ポイント: 判定結果をコピーして障害メモへ残す

FAQ

  • 署名が正しいかも判定できますか?

    できません。署名検証は行わず、期限判定に必要なexp / nbf / iatだけを確認します。

  • expが無いJWTでも判定できますか?

    expが数値で存在しない場合はエラーとして案内します。

  • Bearer付き入力は必要ですか?

    不要です。Bearer付きでも無しでも入力できます。

  • この結果だけで認証可否を判断してよいですか?

    不可です。署名検証やaud・issの確認は別途必要です。

  • payload全体を見たい場合は?

    JWTデコーダーでHeader・Payloadの全クレームを確認できます。

基本FAQ

  • 入力データは外部へ送信されますか?

    原則として送信されません。入力内容はブラウザ内で処理し、URLやアクセス解析へ保存しません。例外がある場合は各ツールページ内に明記しています。

  • 入力内容は自動保存されますか?

    原則として自動保存しません。ページを更新すると入力は失われます。コピーやダウンロードで保存する場合は、ご利用端末内に保存されます。

同じ目的のJWT確認ツール

JWTのpayload確認とexpの期限確認を、貼り付けた文字列だけで確認できます。

同じ作業の前後で使うことがあるツールです。