JWTの有効期限チェッカー
expクレームはUnixタイムスタンプなので、見ただけでは何も分かりません。トークンを貼れば、日付と見慣れたタイムゾーン、そしてひと言の説明になります。
エンドポイントを試すために、自分でトークンに署名できます。計算はすべてこのページの中で行われます。
鍵も出来上がったトークンもブラウザーの中だけに残ります。どこにも送信されず、共有リンクにも含まれません。
このトークンを自分のコードで検証しましょう。サンプルはヘッダーのアルゴリズムに合わせて変わります。
JSON Web Tokenがいつ期限切れになるかを確かめる
拒否されたリクエストが謎のままでいる時間は、たいてい長くありません。まず見るべきは、届いた時点でトークンがまだ生きていたかどうかです。やっかいなのは、その答えが1790208000のような形で入っていて、ひと目では誰にも読めないことです。トークンを貼れば、デコードされたヘッダーの上の行が言葉で答えます——2日前に期限切れ、58分後に期限切れ、まだ有効でない——そしてクレームの表が自分のタイムゾーンでの完全な日付を示します。
すべてページ内でデコードされます。ここではそれが特に大事です。トークンは生きた資格情報で、有効なものを手にした人は、このページが告げているまさにその瞬間まで、その主体として振る舞えてしまうからです。貼り付けたものが送信・記録・保存されることはありません。
時刻を運ぶ3つのクレーム
| クレーム | 意味 | 値が間違っているとどう見えるか |
|---|---|---|
exp | この時刻からトークンは受け入れられなくなる | ログインのたびに決まった時間が経つと出る401 |
nbf | この時刻より前は使えない | 発行したばかりのトークンが最初の数秒だけ拒否される |
iat | 発行された時刻 | 最大経過時間の規則に使われ、期限内でも古いトークンは弾かれる |
3つともUnixエポックからの「秒」であって、ミリ秒ではありません。JavaScriptのDate.now()で手書きしたJWTは西暦58,000年に着地し、どこでも受け入れられません。この数値だけを単独で変換したいときは、タイムスタンプ変換が同じ計算を両方向で行います。
期限切れか、それともずれているだけか
2台の機械が秒まで一致することはまずないので、まともな検証側はいくらか猶予を持たせます。30〜60秒が一般的です。この許容範囲があるから、ここで数秒だけ期限切れに見えるトークンが受け入れられることもあり、時計が進んだサーバーの発行したトークンが最初の数瞬だけまだ有効でないとして拒否されることもあります。その窓から大きく外れて失敗するなら、時計のせいではありません。
答えのもう半分は署名です。期限切れのトークンがまったく正しい署名を持つこともあれば、偽造されたトークンがはるか先のexpを名乗ることもあります。2つの問いは別物です。このページは両方を報告します。トークンの下の鍵で署名を検証すれば、有効という結果の横に期限切れであることも併せて示されます。
トークンはどれくらい生きるべきか
短くです。トークンは取り戻せないからです。いったん署名されれば、持っている人はexpが過ぎるまでその利用者そのものです。15分しか生きないアクセストークンは、30日生きるものには決してできない形で漏洩の被害を抑えます。ふつうは短いアクセストークンと、サーバー側に置かれて失効させられる長いリフレッシュトークンを組み合わせます——まさにセッションクッキーとの比較が扱っている取引です。
原因を追うのではなく、その挙動を試したいのなら、JWTジェネレーターが5分で切れるトークンや、期限のまったくないトークンに署名してくれます。自分のコードがどう反応するかを見られます。