JWTのexpの読み方|有効期限を日本時間で確かめる手順
JWTのexpは、1970年1月1日0時(UTC)から数えた秒数で、決まりどおりに判定すればその時刻ちょうどからトークンは使えなくなります。秒数を日本時間に直す手計算、13桁ならミリ秒で書いた誤りであること、「期限切れ」と言われたときに時計のずれと取り違えを見分ける方法を説明します。
公開読了目安 約5分
この記事の要点
- exp・iat・nbfは、1970年1月1日0時(UTC)から数えた秒数
- ゆとりを持たせない決まりどおりの判定では、expの時刻ちょうどから使えない
- expが13桁なら、秒ではなくミリ秒で書いた誤りを疑う
- expが今より後なのに出る「期限切れ」は、時計のずれを疑う
- 中身が読めても、署名を確かめるまでは本物とは言えない
目次
JWTの exp は、1970年1月1日0時(UTC)から数えた秒数です。
決まりどおりに判定すれば、その時刻ちょうどからトークンは受け付けられなくなります。
日本時間で読むには、秒数をUTCの日時に直してから9時間を足します。
たとえば 1792717200 は、UTCの2026年10月23日1時、日本時間の同じ日の10時です。
この記事では、秒数を日時に直す計算と、「期限切れ」と言われたときの原因の見分け方を説明します。 例の日時は、すべてこのサイトのツールで出した値と突き合わせてあります。
exp・iat・nbfは「1970年からの秒数」
JWTの決まり(RFC 7519)では、時刻を表す項目は1970年1月1日0時(UTC)からの秒数で書きます。 時刻を表す主な項目は、次の3つです。
| 項目 | 意味 |
|---|---|
iat | 発行した時刻 |
nbf | この時刻より前は使えない |
exp | この時刻から使えない |
発行から1時間で切れるトークンなら、中身は次のようになります。
{
"sub": "user-42",
"iat": 1792713600,
"exp": 1792717200
}
exp から iat を引くと3,600秒で、ちょうど1時間です。
有効期間の長さは、日時に直さなくても引き算だけで分かります。
秒数を日本時間に直す手計算
1日は86,400秒なので、秒数を86,400で割ります。 商が1970年1月1日から数えた日数、余りがその日のUTCの時刻です。
1792717200 なら、86,400で割ると商が20,749、余りが3,600です。
1970年1月1日から20,749日後は2026年10月23日で、余りの3,600秒は1時0分0秒です。
UTCの1時に9時間を足すと、日本時間の10時になります。 余りに9時間(32,400秒)を足して86,400を超えたら、日付が1日進みます。
日数から日付を数えるのは手間なので、実際には UNIXタイムスタンプ変換 に入れるのが早く済みます。 秒数とミリ秒の見分けも、桁数から自動で行います。
期限の境目は「expちょうど」から
RFC 7519 は、exp の時刻ちょうど以降に受け付けてはならない、と決めています。
exp が10時0分0秒なら、10時0分0秒にはもう使えません。
nbf は逆向きで、その時刻より前は受け付けてはならない決まりです。
nbf が9時0分0秒なら、9時0分0秒ちょうどから使えます。
iat には、受け付けるかどうかの決まりはありません。
発行からの経過時間を見たいときに使う項目です。
expが13桁ならミリ秒で書いた誤り
JavaScript の Date.now() のように、ミリ秒で時刻を返す仕組みがあります。
その値をそのまま exp に入れると、桁が3つ多い13桁になります。
日本時間の2001年9月9日から2286年11月21日までの秒数は、どれも10桁です。
今の時刻の exp が13桁なら、ミリ秒で書いた誤りと考えてよいでしょう。
1792717200000 を秒として読むと、58778年12月13日になります。
受け取る側が秒として比べると、このトークンは5万年以上先まで期限切れになりません。
UNIXタイムスタンプ変換に同じ13桁を入れると、ミリ秒として読んで2026年10月23日10時と出ます。
JWTの決まりでは秒で書くので、JWTの exp としては誤りのままです。
「期限切れ」と言われたときの見分け方
トークンを受け取る側(サーバー)が「期限切れ」と返すとき、時刻にかかわる原因は次の3つに分けて確かめられます。
どれなのかは、exp の日時と、有効期間を延ばしたときの変わり方で見分けます。
- 本当に期限が過ぎた:
expを日時に直すと、今より前の時刻になっています。取り直せば通ります。 - 時計がずれている:
expは今より後なのに、期限切れと言われます。受け取る側の時計が進んでいるか、発行する側の時計が遅れていると、この形になります。有効期間を、ずれより長くすると通ります。 - 秒とミリ秒を取り違えている: 発行した直後から、必ず期限切れになります。受け取る側が、秒の
expをミリ秒の今の時刻と比べている形です。有効期間を何時間に延ばしても直りません。
時計のずれは、「発行してすぐなのに、まだ使えない」という形でも出ます。
発行した側の時計が進んでいると、nbf が受け取る側にとって未来の時刻になるためです。
RFC 7519 は、時計のずれに備えて数分程度のゆとりを持たせてよい、としています。 ゆとりを持たせるかどうかは、受け取る側の作りしだいです。
ゆとりを持たせた受け取り側では、exp を少し過ぎても受け付けます。
この記事の「ちょうどから使えない」は、ゆとりの無い決まりどおりの境目で、このサイトのデコーダーもこの境目で判定します。
読めることと、本物であることは別
. で3つに分かれた署名付きのJWTは、鍵が無くても誰でも中身を読めます。
ヘッダーとペイロードは、文字に直してあるだけで、暗号にはなっていません。
そのため、exp が未来の時刻でも、そのトークンが本物とは限りません。
本物かどうかは、受け取る側が鍵で署名を確かめて初めて分かります。
JWTデコーダー は中身を読んで、exp と nbf を今の時刻と比べるだけです。
「有効」と出ても、署名まで確かめたという意味ではありません。
期限内のトークンは、持っているだけでログインした人として扱われることがある値です。 中身を確かめるときは、入力を外へ送らない道具を使いましょう。
関連記事
- JWTの中身を安全に確認する使い方|ヘッダーとペイロードを読む:デコーダーの操作の手順
- UNIXタイムスタンプを日時に変換する使い方|秒・ミリ秒を自動判定:秒数と日時を行き来する操作
- UTCと日本時間の違い|時差がサマータイムでずれる理由:UTCと日本時間の関係
- 2038年問題とは|日本時間で何時に起きて何が困るか:秒数が32ビットに収まらなくなる日
まとめ
exp・iat・nbf は、1970年1月1日0時(UTC)からの秒数です。
86,400で割れば日数と時刻に分かれ、UTCに9時間を足すと日本時間になります。
決まりどおりの判定では、exp の時刻ちょうどから、トークンは使えません。
13桁の exp はミリ秒の誤りで、「期限切れ」は有効期間を延ばして直るかで原因を分けられます。
参考・出典
- RFC 7519: JSON Web Token (JWT)(4.1.4 exp / 4.1.5 nbf / 4.1.6 iat) — IETF (2026-10-23 閲覧)
本記事は上記の公的機関・公式情報源を参考にしています。最新の情報は各リンク先をご確認ください。
あわせて読みたい
同じテーマ・関連ツールの記事です。