JWTデコーダー

JWTデコーダーについて

JWT(JSON Web Token、RFC 7519)は、ヘッダー・ペイロード・署名の3つをドットでつないだ文字列です。前の2つはJSONをbase64urlでエンコードしたもので、このツールはそれをデコードしてJSONとして表示し、exp・iat・nbfを日時に直します。

このツールは署名を検証しません。HS256なら共有秘密鍵、RS256やES256なら発行者の公開鍵が必要ですが、デコーダーはどちらも受け取らないからです。ペイロードがきれいに表示されたことは「形式が正しい」ことを示すだけで、「信頼してよい」ことは示しません。

ペイロードは暗号化されていない

base64urlは暗号ではなく表記の変換です。ログやブラウザのlocalStorageからトークンを手に入れた人は、誰でも中身を読めます。署名付きJWT(JWS)のペイロードにパスワードやマイナンバー、社内の権限ルールを入れてはいけません。中身を隠したいならJWE(暗号化JWT)を使います。JWEはドットで区切られた部分が5つあるため、このツールでは「セグメント数エラー」になります。

署名が保証するのは改ざんされていないことです。roleをuserからadminに書き換えて再エンコードすれば、デコーダーにはadminと表示されますが、正しく実装されたサーバーは署名不一致で拒否します。

algヘッダーを信じたときに起きる攻撃

ヘッダーのalgは攻撃者が自由に書き換えられる値です。RFC 8725(JWTのベストプラクティス)は、これを信用したことで起きた代表的な問題を挙げています。

• alg: none:RFC 7519の6章は署名が空文字列の「保護されていないJWT」を定義しています。一部のライブラリはnoneを見て検証を省きました。下の例のように最後のドットの後ろが空のトークンがこれです。
• RS256とHS256の取り違え:サーバーがRSAの公開鍵で検証する設定のとき、攻撃者がalgをHS256に変え、公開鍵をHMACの秘密鍵として署名すると、ヘッダーに従う実装はその偽造を受け入れてしまいます。
• 対策は、検証側のコードで許可するアルゴリズムを固定することです。RFC 8725は、呼び出し側が許可リストを指定できなければならず、それ以外のアルゴリズムを使ってはならないとしています。
• HS256の鍵が短い、または覚えやすい文字列だと、トークン1つからオフラインの総当たりで鍵を割り出されます(RFC 8725 2.2節)。

exp・nbf・iatと時計のずれ

3つとも1970-01-01 UTCからの「秒」です。JavaScriptのDate.now()はミリ秒なので、自作トークンで1000倍の扱いを間違えると、有効期限が数万年先や1970年になります。表示された日時が極端なら、まずこれを疑ってください。

RFC 7519では、exp以降は受け入れてはならず、nbfより前も受け入れてはなりません。どちらにも時計のずれに備えて「通常は数分以内の小さな猶予(leeway)」を設けてよいと書かれています。発行サーバーの時計が30秒進んでいると、受け取ったばかりのトークンがnbfで拒否されることがあります。

このツールの「期限切れ」と「まだ有効ではない」(nbfより前)の表示は、あなたのPCの時計とexp・nbfを比べた結果です。「時計のずれの許容(秒)」に値を入れるとその分の猶予を持たせて判定します(初期値0秒)。iatが未来ならば時計のずれを警告します。iatは発行時刻にすぎず、expがないトークンは規格上期限がありません。

例

使い方

1. 「Bearer 」を除いたトークン本体を貼り付けます。
2. ヘッダーのalg・typとペイロードのクレームを確認します。
3. exp・iat・nbfの日時を見ます。期限切れ・nbfの判定はPCの時計と、入力した許容秒数が基準です。

よくある質問