JWTトークンの中身が丸見え？知らないと怖い認証トークンの仕組みと安全な扱い方
#security
導入：「トークンは暗号化されてるから安全」は大嘘
「博士！ APIのログイン処理でJWTトークンを使ってるんだけど、これって暗号化されてるから中身は安全だよな？」
「それは大きな誤解じゃ！ JWTは暗号化（Encryption）ではなく、署名（Signing）しているだけ。つまり、中身は誰でも読めるのじゃよ。」
「えっ、じゃあJWTにパスワードとか個人情報を入れてたら…」
「その通り。Base64デコードするだけで全部丸見えになるのじゃ。」
1. JWTの中身が見える実験：3秒で暴かれる情報
「JWTトークンは3つの部分がドット（.）で区切られておる。Header.Payload.Signatureの構造じゃ。」
JWTトークンの構造
eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMjM0NX0.SflKxwRJSMeKKF2QT4fwpM...■ Header（アルゴリズム情報） ・■ Payload（ユーザー情報） ・■ Signature（署名）
「赤と青の部分をBase64デコードしたら読めちゃうってこと？ やばいぜ！」
JWTに絶対に入れてはいけない情報
- パスワード：平文でもハッシュ値でもNG
- クレジットカード情報：PCI DSSの重大な違反になる
- メールアドレスや電話番号：個人情報保護法に抵触する恐れ
- 秘密鍵やAPIキー：アクセストークン経由で漏洩するリスク
「JWTのPayloadに入れていいのは、ユーザーID、有効期限（exp）、権限レベル（role）くらいね。最小限の情報に留めるのが鉄則よ。」
2. JWTデコードツールを使った実務活用シナリオ
「JWTデコードは、デバッグや障害調査で非常に役立つスキルじゃ。」
シナリオ1: 「認証が通らない」トラブルの調査
APIリクエストで401エラーが返ってくるとき、最初に確認すべきはJWTの有効期限（exp）です。 トークンをデコードして exp フィールドの値（UNIXタイムスタンプ）を確認すれば、 期限切れが原因かどうかが即時に判定できます。
シナリオ2: 権限エラーのデバッグ
「管理者なのに管理画面にアクセスできない」というケースでは、JWTの role や scope フィールドを確認します。 ログイン時に古いトークンがキャッシュされており、最新の権限が反映されていないことがよくあります。
当サイトのJWTデコードツールにトークンを貼り付ければ、 Header・Payload・署名情報を即座に可視化できます。本番のトークンも安全にデコードできます（データはサーバーに送信されません）。
3. プロが教える「一歩先の」テクニカルTips
「JWTを安全に運用するための、プロの知恵を伝授しよう。」
Tips 1: アルゴリズムの「none」攻撃に注意
過去にJWTのアルゴリズムを none に設定することで署名検証を迂回できる脆弱性が多くのフレームワークで発見されました。 サーバー側では必ずアルゴリズムをホワイトリストで検証し、none を受け入れないようにしてください。
Tips 2: リフレッシュトークンの仕組みを理解する
アクセストークン（JWT）の有効期限は短く（15分〜1時間）設定し、リフレッシュトークンで新しいJWTを再発行する構成が推奨されます。 リフレッシュトークンはJWTではなく、不透明な（opaque）ランダム文字列をDB管理するのが安全です。
🚨 現場の注意点：JWTはlocalStorageに保存しない
JWTを localStorage に保存するとXSS（クロスサイトスクリプティング）攻撃でトークンが盗まれるリスクがあります。 代わりに HttpOnly 属性付きのCookieに保存し、JavaScriptからアクセスできないようにするのがセキュリティのベストプラクティスです。
「JWTは便利じゃが、『暗号化されている』という誤解が一番危険じゃ。 まずはJWTデコードツールで自分のトークンの中身を確認して、意図しない情報が含まれていないかをチェックするのじゃ！」