JWT — 取り消せない代わりに、問い合わせが要らない

What — トークンの中身は誰でも読める

JWT は3つの部分をドットで繋いだ文字列です。暗号化ではなく、署名である点が最重要です。

クレーム

ペイロードに入る各項目。sub（誰か）、exp（いつまで）、iat（いつ発行）などが標準で定義されている。

HS256

共通鍵方式。発行も検証も同じ秘密鍵を使う。検証する側にも秘密鍵を配る必要がある。

RS256

公開鍵方式。発行は秘密鍵、検証は公開鍵。検証側に秘密鍵を渡さずに済むため、複数サービスで検証したい場合に向く。

アクセストークン

API 呼び出しに使う短命なトークン。JWT が使われることが多い。

リフレッシュトークン

アクセストークンを再発行するための長命なトークン。サーバーが状態を持って管理するのが一般的。

セッションとの本質的な違い

1. Cookie から sid を取り出す
2. Redis に sid で問い合わせる  ← ネットワーク往復
3. 見つからなければ未認証
4. ユーザー情報を得る（最新）

Why — なぜ「取り消せない」のか

JWT の性質は、たった1つの設計判断から導かれます。

検証時に、発行元へ問い合わせない。

問い合わせないから速い。問い合わせないからサービスをまたいで検証できる。そして、問い合わせないから「このトークンは無効になりました」を知る手段がない。

利点も欠点も、すべてこの1点から出ています。片方だけを取ることはできません。

これは DNS の TTL とまったく同じ構造です。答えを配ったら、期限が来るまで取り消せない。取り消せないから速い。キャッシュを持つシステムが必ず抱える宿命であり、JWT は認証情報をキャッシュしていると見ると理解しやすくなります。

失効させる3つの手段と、その代償

実務でよく使われるのは1番目です。アクセストークンを短命にし、失効可能なリフレッシュトークンをサーバーで管理するという組み合わせ。アクセストークン検証は問い合わせ不要のまま、失効の実効性を「数分の猶予つき」で確保できます。

よくある実装ミス

① alg: none を受け入れてしまう

ヘッダの alg をトークン側の申告として読み、none なら署名検証をスキップする実装があります。攻撃者は好きな内容のトークンを作れます。サーバー側で期待するアルゴリズムを固定してください。

② localStorage に保存する

JavaScript から読めるため、XSS が1つあればトークンを丸ごと持ち出されます。HttpOnly Cookie なら、XSS があってもトークン本体は読み出せません。

③ 有効期限を長く取る

「毎回ログインさせたくない」という理由でアクセストークンを数日〜数週間にすると、盗まれたときの被害期間がそのまま長くなり、失効も効きません。長寿命が必要なのはリフレッシュトークンのほうです。

④ ペイロードに機密情報を入れる

メールアドレス、電話番号、内部 ID。Base64 は暗号ではないので、すべて読まれます。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。