暗号技術・PKI・認証基盤 重要度:★★★出題: AM2・PM1
JWT / JWS (JSON Web Token / Signature)
じぇいそんうぇぶとーくん / JSON Web Token (RFC 7519) / JSON Web Signature
ヘッダ・ペイロード・署名の3パートをドット連結したBase64URL形式のトークンであり、ステートレスな認証・認可情報伝達に広く用いられる規格。
3行速習ポイント
- Header（アルゴリズム等）、Payload（クレーム：sub, iss, aud, exp等）、Signature（改ざん検知署名）の3部構成
- JWS（署名付きJWT）のペイロードはBase64URLエンコードされているだけで暗号化ではないため、機密情報の格納は厳禁（暗号化にはJWEを使用）
- alg: none 攻撃や公開鍵/共通鍵アルゴリズム混同攻撃（RS256→HS256書き換え）を防ぐため、サーバ側で許可アルゴリズムを固定検証する
図解
図JWT / JWS の3パート構造と署名バイパス防御原則
1. Header
Header（ヘッダ部）と alg 固定検証
署名アルゴリズム指定と alg:none / 鍵混同攻撃対策
トークン内のalg指定を盲信せず、検証側プログラムで許可する署名アルゴリズム（例：RS256のみ）を固定指定して署名バイパスを阻止
2. Payload
Payload（ペイロード部：クレーム検証）
sub・iss・aud・exp 等の属性情報（非暗号化）
発行者（iss）、対象受信者（aud）、有効期限（exp）を厳格に検証。ステートレスで失効しにくいため有効期限は短く設定
3. Signature
Signature（署名部：改ざん検知）
Header.Payload に対するHMACまたは公開鍵署名
ペイロードの権限（role: admin等）が1文字でも改ざんされると署名検証が不一致となり、不正な権限昇格を確実に検知・拒否
💡 JWSのペイロードはBase64URLエンコードされているだけで誰でもデコード閲覧可能なため、パスワードや機密情報の格納は厳禁
概要と本質
マイクロサービスやSPA（Single Page Application）、OIDCのIDトークンとして標準利用されています。サーバ側でセッション状態を保持せずに署名検証だけでトークンの正当性を確認できる一方、実装不備による署名バイパス脆弱性や有効期限（exp）管理が重要な論点となります。
重要ポイント・コア概念
- algヘッダ改ざん対策：トークン内のalg指定を盲信せず、検証側プログラムで期待する署名アルゴリズム（例：RS256のみ）をハードコード指定
- 必須クレーム検証：署名検証に加え、iss（発行者）、aud（対象受信者）、exp（有効期限）のすべてを検証
- 失効管理の課題：ステートレスなJWTは一度発行すると有効期限まで無効化しにくいため、有効期限を短く設定しリフレッシュトークンと併用
午後記述・情報セキュリティ対策での攻略ポイント
午後問題では「JWTのペイロードを書き換えて管理者権限へ昇格する攻撃がなぜ防げるのか（署名が一致しなくなるため）」「なぜJWTのペイロードにパスワードやクレジットカード番号を入れてはいけないのか（Base64URLは誰でも復号・閲覧できるため）」が問われます。
午後記述で使える加点キーワード（クリックでコピー）
関連する重要用語
この用語が出題された過去問を解く（1分演習）
即時アウトプットで定着情報処理安全確保支援士 過去問演習で実践力を鍛える
