JWT
本文约需 2 分钟阅读
JWT (JSON Web Token) とは、 JSON 形式のデータに電子署名を付与してコンパクトな文字列に エンコードしたトークンです。 2015 年に RFC 7519 として標準化され、OAuth 2.0 のアクセストークンやシングルサインオン (SSO) の アサーションとして広く利用されています。サーバー側にセッション情報を保持しない ステートレスな認証を実現できる点が最大の特徴であり、マイクロサービスアーキテクチャの 普及とともに採用が急速に拡大しました。
3 パート構造 - Header.Payload.Signature
JWT はドット (.) で区切られた 3 つのパートで構成されます。 それぞれ Base64URL エンコードされており、人間が直接読むことはできませんが、 デコードすれば JSON として内容を確認できます。
JWS と JWE の違い
JWT という用語は日常的に「署名付きトークン」の意味で使われますが、仕様上は JWS (JSON Web Signature) と JWE (JSON Web Encryption) の 2 種類が存在します。
Payload は Base64URL エンコードされているだけで、デコードすれば誰でも中身を読める。 署名によって改ざんの検知は可能だが、内容の秘匿はできない。 一般的に「JWT」と呼ばれるものの大半はこの JWS 形式。
Payload 自体を暗号化し、 復号鍵を持つ者だけが内容を読める。 5 パート構造 (Header, Encrypted Key, IV, Ciphertext, Authentication Tag) になる。機密情報をトークンに含める必要がある場合に使用。
実務では JWS が圧倒的に多く使われます。 Payload に個人情報や機密データを含めないことが 前提であり、含める必要がある場合は JWE を検討するか、そもそもトークンに含めない設計に 見直すべきです。
ステートレス認証の利点とリスク
JWT によるステートレス認証では、サーバーがセッション情報を保持しません。 トークンの署名を検証するだけで認証が完了するため、セッショントークンを Redis やデータベースで管理する必要がなく、水平スケーリングが容易です。
| 観点 | JWT (ステートレス) | Cookie セッション (ステートフル) |
|---|---|---|
| サーバー側の状態 | なし (トークン自体に情報を含む) | あり (セッションストアが必要) |
| スケーラビリティ | 高い (どのサーバーでも検証可能) | セッション共有の仕組みが必要 |
| 即時失効 | 困難 (ブラックリスト方式が必要) | 容易 (セッションを削除するだけ) |
| トークンサイズ | 大きい (数百バイト〜数 KB) | 小さい (セッション ID のみ) |
| CSRF 耐性 | Authorization ヘッダー使用時は耐性あり | SameSite 属性等の対策が必要 |
最大のリスクは「一度発行した JWT を即座に無効化できない」点です。ユーザーがパスワードを 変更しても、漏洩した JWT は有効期限まで使い続けられます。この問題を緩和するため、 アクセストークンの有効期限を短く (15 分程度) 設定し、リフレッシュトークンで再発行する パターンが一般的です。即時失効が必須の要件では、サーバー側にブラックリストを持つか、 Cookie ベースのセッション管理を選択すべきです。
JWT を狙う代表的な攻撃
Header の alg フィールドを "none" に書き換え、署名検証をバイパスする攻撃。初期のライブラリには alg:none を受け入れる実装が多く存在した。対策として、サーバー側で許可するアルゴリズムを明示的にホワイトリスト指定する。
RS256 (非対称鍵) で署名されたトークンの alg を HS256 (対称鍵) に書き換え、公開鍵を HMAC の秘密鍵として使う攻撃。公開鍵は誰でも入手できるため、攻撃者が有効な署名を生成できてしまう。
HS256 の秘密鍵が短い文字列や推測可能な値だと、ブルートフォースで鍵を特定される。最低 256 ビット以上のランダムな鍵を使用し、定期的にローテーションすることが必須。
セッションハイジャックの 手法は JWT にも適用されます。暗号化の基礎知識と あわせて理解しておくことが重要です。セッションハイジャック対策、セッショントークン窃取の防御策、API キー管理のベストプラクティスも あわせて参照してください。Web 認証の関連書籍 (Amazon)で体系的に学ぶことを推奨します。
这篇文章对您有帮助吗？