JWTは「透明な箱」である：機密情報の投棄とJWEによる再設計のパラダイム
多くの開発者が陥る最初の罠は、JWT（JSON Web Token）を「セキュアなコンテナ」だと誤認することだ。結論から言えば、JWTのペイロードはBase64Urlエンコードされているだけであり、ネットワークを流れるパケットをキャプチャし、[jwt.io](https://jwt.io/)に放り込めば、誰でも中身を「読める」。
我々ホワイトハッカーがペネトレーションテストで最初に行うのは、このペイロードのデコードだ。もしそこにユーザーのメールアドレス、内部ロール、あるいは（最悪なことに）APIキーやデータベースのIDが含まれていれば、攻撃の足がかりは完成したも同然だ。
1. なぜ「署名」だけでは不十分なのか
JWTの「S」はSignature（署名）を指す。これは「改ざん検知」には有効だが、「機密保護」には一切寄与しない。
攻撃者は、署名を検証する前のパケットを傍受し、ペイロードを書き換えて再構築する。もしアプリケーション側が署名の検証プロセスで`alg: none`を許容する脆弱性（かつて多くのライブラリで散見された）を抱えていれば、署名は単なる飾りと化す。
ここで重要なのは、「JWTのペイロードには、公開されても困らない情報（ユーザーIDや有効期限など）のみを載せる」という鉄則だ。だが、アーキテクチャ上、どうしても機密を含んだトークンを渡さなければならないシチュエーションがあるとしたら？ そこで登場するのがJWE（JSON Web Encryption）だ。
2. JWE：機密性を担保する鍵
JWEは、JWTのペイロードを暗号化することで、信頼できないエンドポイント間での安全なデータ交換を実現する。
// JWEの構造イメージ
// Header (暗号化アルゴリズムの指定)
{
“alg”: “RSA-OAEP-256”,
“enc”: “A256GCM”
}
// 続いて、暗号化されたコンテンツが続く
JWEを適用する際は、以下の構成要素を理解しておく必要がある。
- Key Management (alg): 鍵の共有方法。RSAやECDHが使われる。
- Content Encryption (enc): 実際のペイロードを暗号化するアルゴリズム（AES-GCMが推奨）。
実装の勘所：JWEライブラリの選定と注意点
Node.js環境であれば、`jose`ライブラリ一択だ。古い`node-jsonwebtoken`はJWEのサポートが限定的であるため、モダンなアーキテクチャでは避けるべきだ。
import { EncryptJWT, generateKeyPair } from ‘jose’;
// 鍵ペアの生成（実運用ではKMS等から取得）
const { publicKey, privateKey } = await generateKeyPair(‘RSA-OAEP-256’);
// JWEの作成
const jwt = await new EncryptJWT({ ‘sensitive-data’: ‘secret-value-123’ })
.setProtectedHeader({ alg: ‘RSA-OAEP-256’, enc: ‘A256GCM’ })
.setIssuedAt()
.setExpirationTime(‘2h’)
.encrypt(publicKey); // 公開鍵で暗号化
console.log(jwt); // これで中身は完全に秘匿される
3. 次世代の脅威を見据えたガードレイル
我々が今、真剣に検討すべきは「耐量子暗号（PQC）」への移行だ。RSAや楕円曲線暗号（ECDSA/ECDH）は、将来的な量子コンピュータの実用化により、秘密鍵が暴かれるリスクを孕んでいる。
現時点でJWEを設計する際は、暗号スイートの更新を容易にするよう、暗号化アルゴリズムをハードコーディングせず、設定ファイルやKMS（AWS KMS, Google Cloud KMS）のキーポリシーで制御する設計（Agility）が必要だ。
また、生成AIがコードを生成する昨今、開発者が「JWTのペイロードに何を入れるか」という判断をAIに委ねるケースも増えている。ここで重要になるのが、CI/CDパイプラインにおける「トークン監査」の自動化だ。
推奨されるガードレイル監査プロセス
1. 静的解析: CI環境で正規表現を用いて、JWT生成コードのペイロードにメールアドレスや個人情報が含まれていないかチェックする。
2. 動的監査: 開発環境で出力されるJWTをインターセプターでキャッチし、パケットをパースして機密情報が含まれていないかを確認するUnit Testを実装する。
3. KMS統合: トークンの署名・暗号化鍵をアプリケーションメモリに置かず、常にHardware Security Module (HSM) 経由で操作する。
結論：プロフェッショナルの矜持
JWTは便利なツールだが、それは「使い方を誤れば毒にもなる」ということを忘れてはならない。署名があるから安全だという思考停止は、エンジニアとして最も避けるべき態度だ。
あなたがチーフホワイトハッカーとして設計に携わるなら、JWTを単なる認証手段としてではなく、「データが通過する境界線において、どの情報が可視化され、どの情報が秘匿されるべきか」という境界防衛の論理として捉え直してほしい。
JWEはコストがかかる。だが、大規模な情報漏洩が引き起こすレピュテーションリスクと、その後の泥臭いインシデントハンドリングに費やす膨大な工数を考えれば、実装コストは極めて安い保険だ。
次にトークンを設計する時、その中身を覗き見られる準備ができているか。その問いを常に自分に投げかけ続けてほしい。それが、プロのエンジニアの流儀である。
コメント