本文へ移動
JWT デコーダー
サンプル JWT の構造と期限を確認。署名検証なし。
ブログ

JWTのexpは何時? 試験用トークンで1時間の差を確認

そのJWTは読めるだけか、検証済みか。架空の2本でUTC時刻とroleを比べ、期限表示だけでは認証を判断できない理由を確かめます。

JWTの中身が読めても、そのトークンが本物か、ログインできるかは別の問題です。まず架空の1本でexpの時刻を確かめ、そのあとroleだけを変えた2本目と比べてみましょう。読む操作と検証を、画面上で区別する練習です。

本番のアクセストークンは入力しないでください。 以下は当サイトが説明のために作成した架空のデータです。subはexample-user、署名に相当する3番目の部分はexample-not-a-signatureをbase64url化した文字列で、暗号署名を作成していません。実際の鍵・利用者・認証情報は使っておらず、サーバーへログインするための例でもありません。

1本目:iatとexpをUTCで読む

日本語のJWTデコーダーを開き、次の1本を入力欄に貼り付けます。画面上の折り返しは表示だけです。選択するのはドットでつながった1本の文字列で、コード欄の末尾の改行は除いてください。これはツールの内蔵サンプルとは別の例なので、「サンプル」ボタンではなく下の文字列を使います。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJleGFtcGxlLXVzZXIiLCJpYXQiOjE3MDAwMDAwMDAsImV4cCI6MTcwMDAwMzYwMCwicm9sZSI6InJlYWRlciJ9.ZXhhbXBsZS1ub3QtYS1zaWduYXR1cmU

期待するpayloadは、sub: "example-user"、iat: 1700000000、exp: 1700003600、role: "reader"です。時刻は次のように表示されます。

確認する値秒数UTCの時刻
iat17000000002023-11-14T22:13:20.000Z
exp17000036002023-11-14T23:13:20.000Z

1700003600 − 1700000000 = 3,600秒 = 1時間。これはpayloadが記載する時刻の差で、実際に1時間使えることを証明しません。RFC 7519のNumericDateは、1970-01-01T00:00:00Zからの経過時間をミリ秒ではなく秒で表します。

この例の期限は2023年なので、2026年10月11日の検査では「記載の期限に到達・経過」と「未検証」が同時に表示されました。期限比較は端末の入力時点の時刻が基準です。画面に出る入力時点のUTC時刻は毎回同じではなく、放置した後の継続監視やサーバー時刻との同期でもありません。

2本目:roleがadminと読めても、権限は確認できない

次は同じ時刻・同じ説明用の署名部分のまま、roleをreaderからadminへ変えたものです。1本目の代わりに貼り付けて、payloadと「未検証」の表示を比べてください。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJleGFtcGxlLXVzZXIiLCJpYXQiOjE3MDAwMDAwMDAsImV4cCI6MTcwMDAwMzYwMCwicm9sZSI6ImFkbWluIn0.ZXhhbXBsZS1ub3QtYS1zaWduYXR1cmU
比べる点1本目2本目
roleの文字readeradmin
iatとexp上のUTC時刻同じUTC時刻
本ツールの署名・権限確認未検証未検証

この比較で分かるのは、読み取れた文字と確認済みの権限は違うことです。「admin」という文字を見たからといって管理者扱いにしてはいけません。実在するサービスのトークンを書き換えたり、改変したトークンを送る実験ではありません。

本ツールはheader.payload.signatureの3部分を読むデコード専用です。RFC 7515の検証処理は実装していません。alg: HS256という表示もヘッダーに書かれた値にすぎず、受け入れてよいアルゴリズムだという確認ではありません。RFC 8725は、検証側で許可するアルゴリズムを定めることや、発行者・対象を確認することを扱っています。

期限表示がないとき・401が出たとき

数値のexpがない場合や、日時に換算できない場合、このツールには期限バッジが出ません。表示なしは「無期限で有効」ではありません。 また、期限前という表示だけで、署名・発行者・対象・権限が正しいともいえません。デコーダーだけで401 の原因を確定することはできません。

実際の障害を調べるときは、組織で承認されたローカル手順とサーバーの検証結果を使ってください。RFC 6750で扱うbearerトークンは、持っている人が利用できる認証情報です。Webツールへ本番の値を貼らず、漏えいが疑われたら発行元の失効・ローテーション手順を確認します。

このサイトのデコード処理はブラウザー内で行いますが、ブラウザー拡張・端末環境を含めて本番の認証情報の安全を保証するものではありません。形式の練習にはここにある架空の2本を使い、JSONだけを確認するなら日本語JSON整形ツールへ進めます。自分の認証情報を保存用の記事メモや共有URLに入れる必要もありません。

よくある質問

この2本でログインできますか?
いいえ。署名部分は説明用文字列をbase64url化しただけで、暗号署名を作成していません。実際の利用者やサービスの認証情報ではありません。デコード表示はログイン成功を意味しません。
expはミリ秒ですか?
RFC 7519のNumericDateはUTCの1970年1月1日からの秒数です。この例の1700003600は2023年11月14日23:13:20 UTCで、ミリ秒をそのまま入力する値ではありません。
expがなければ無期限で有効ですか?
そうとはいえません。このツールは数値のexpを換算できる場合にだけ期限を表示します。expなし・数値でない値・換算できない値を有効と判定する機能はありません。実際の受け入れ条件は発行元と利用先の検証規則で確認してください。
期限前なら401の原因は権限不足ですか?
期限表示だけでは決められません。署名、発行者、対象、利用先の規則はこのツールで検証しません。本番の障害は承認された手順でサーバーの検証結果を確認してください。
本番のアクセストークンを貼っても大丈夫ですか?
本番のbearerトークンはWebサイトへ貼り付けないでください。変換処理がブラウザー内でも、ブラウザー拡張や端末環境を含む安全性は保証できません。以下の架空の例か、自分の承認されたテスト用データだけを使います。漏えいが疑われる場合は発行元の失効・ローテーション手順に従ってください。

出典

確認記録: Codex AIによる出典・算術・コード確認。人間の保安専門家による独立監査ではない

確認内容と限界を開く

RFC 7519のNumericDate・exp・iat、RFC 7515のcompact構造、RFC 6750のbearerリスク、RFC 8725のアルゴリズム・issuer/audience検証を確認。元の本文全体をこれらと現在のdecodeJwtコードで再確認し、完全な架空の2本、UTC換算、期限境界、鍵なしの表示と検証の区別へ改稿した。署名は作成せず公開の説明用文字列のみ。実運用トークン、サーバー認証、全ブラウザーは検査していない。旧装飾画像は原稿との整合を再確認できないため参照を外し、古い外部パッケージは再発行しない。

この記事で加えたこと — 独自に作成した架空の2本をそのまま試せるよう掲載し、iatとexpのUTC時刻・3,600秒の差と、roleだけを変えても同じ未検証表示になることを実装と独立したデコードで照合する。署名部分は説明用文字列であり実際の鍵や認証情報ではない。

確認記録は記載された確認内容であり、独立した正確性の保証ではありません。

ツールに戻る →