JWT デコード — 暗号化ではない

自作の偽トークンをbase64デコードして、JWTの中身が誰でも読めることを体感します。署名は改ざん検知であって秘匿ではありません。

第2章 / 全5章目安約3分この章のゴール: JWTが暗号化ではなくエンコードであり、中身に秘密を入れてはいけないと理解する

この章は攻撃者の視点を体験します(自作環境専用)。下の枠で扱うのは、この教材が用意した架空のトークンだけです。他人の本物のトークンを勝手にデコード・保存・利用してはいけません(法と倫理)。

JWT(JSON Web Token)は、ログイン状態を表すために広く使われるトークンです。xxxxx.yyyyy.zzzzz のように、ピリオドで3つに区切られた長い文字列を見たことがあるかもしれません。ここでよくある誤解が一つあります——「長くて読めないから、暗号化されている」。

これは違います。触って確かめます。

法と倫理ゲート

手を動かす前に

このコースは攻撃の技術に触れます。実習してよい相手は、次の3つだけです。

実在する第三者のシステムを許可なく触ることは、不正アクセス禁止法に触れます。このゲートは、その線引きを毎回の入口で確かめるためのものです。詳しくは「セキュリティの法と倫理」へ。

上の (a)(b)(c) の範囲だけで実習することに同意します。

同意すると、この先の内容が表示されます。

下の枠には、サーバから渡されたつもりの架空の JWT が表示されています。「デコードする」を押してください。

隔離された練習場この枠の中は、あなたのブラウザの中だけで動く使い捨てのサンドボックスです。ここで起きたことは外に出ません(親サイトの Cookie も保存データも触れません)。扱うのはすべて架空のデータです。

鍵は一切使っていません。 ボタンがやっているのは、1つめ(ヘッダー)と2つめ(ペイロード)を base64url から戻しただけです。それだけで、role や name といった中身がそのまま読めました。

JWT の1つめ・2つめは、暗号化ではなく base64url エンコードです。エンコードは「読みやすい形に変換しただけ」で、鍵がなくても誰でも元に戻せます。
3つめの署名は、「中身が改ざんされていないこと」をサーバが確かめるためのものです。改ざん検知であって、秘匿ではありません。

補足として、いま見ているのは広く使われる署名付きの JWT(JWS)です。まれに中身そのものを暗号化する形式(JWE)もあり、そちらは鍵がないと読めません。ここでは最もよく出会う JWS を扱います——両者の使い分けは、認証・認可トラックの JWT コースで踏み込みます。

ここから2つの実務的な教訓が出ます。

中身に秘密を入れない。 パスワードや、見られて困る個人情報をペイロードに入れると、トークンを持つ人全員に読まれます。
署名の検証を省かない。 中身は誰でも読めますが、勝手に書き換えられないのは署名のおかげです。サーバが署名を検証しなければ、攻撃者は中身を好きに書き換えられます(この「検証の甘さ」を突く攻撃は、認証・認可トラックの JWT コースで扱います)。

見えているものは、秘密ではない。 クライアントに渡した時点で、その中身は読まれる前提で設計する。これはトークンに限らず、ブラウザに送るものすべてに言えます——それを次の章で、もう一段はっきり見ます。

卒業まであと2章です。

この章はまだ完了していません。