情報処理安全確保支援士 2022年 春期 午後2 問02

解答の論理構成

• 【問題文】には、 「F氏：CDNでは、インターネット上にaサーバというサーバを分散配置して、動画配信を要求した端末に最も近いaサーバから動画を配信するようにします。aサーバは、動画配信を要求されたとき、要求された動画を保持していれば代理応答し…」
  と記載されています。
• 「要求された動画を保持していれば代理応答する」という動きは、CDNがデータを一時保存（キャッシュ）し、元のサーバに取りに行かずに応答する仕組みと一致します。
• CDNでコンテンツを保持して配信するサーバは一般に「キャッシュサーバ」と呼ばれ、CDN解説資料やRFCでも同義語として用いられています。
• 以上から、a に入る語は「キャッシュ」と判断できます。

誤りやすいポイント

• 「エッジサーバ」と誤答するケース
  ‐ CDN では確かに “エッジ” という言葉も使われますが、本文では「保持していれば代理応答」というキャッシュ機能を説明しており、より直接的に「キャッシュサーバ」を指しています。
• 「プロキシサーバ」と混同するケース
  ‐ プロキシも代理応答しますが、本文は CDN 内部の動きを説明しており、プロキシよりもキャッシュサーバの語が一般的かつ適切です。

FAQ

解答の論理構成

1. 【問題文】の会話で、Cさんが「その仕組みによって、b攻撃への耐性も向上しますね」と述べています。ここでの「その仕組み」とは、直前の F氏の説明にある「CDNでは、インターネット上にaサーバというサーバを分散配置して、動画配信を要求した端末に最も近いaサーバから動画を配信する」という CDN の分散キャッシュ機構です。
2. CDN は、攻撃トラフィックが発生しても世界各地のノードで分散吸収し、オリジンサーバ（X社動画サーバ）に到達する前に遮断・緩和できます。この特性が強いのは「分散型サービス拒否（Distributed Denial of Service）」、すなわち “DDoS 攻撃” です。
3. 上記より、b に当てはまる英字 5 字以内の語は「DDoS」であると導かれます。

誤りやすいポイント

• DoS と DDoS の混同
  “DoS” は単一元からの攻撃でも該当しますが、CDN の効果が顕著なのは多数のボットから送られる “DDoS” です。文字数条件も「DDoS」が適合します。
• CDN の効果を「CSRF や SQLi の防御」と誤解
  CDN は主にネットワーク負荷分散・キャッシュによる可用性向上策で、Web アプリケーション層の脆弱性攻撃に直接対処するものではありません。
• “DNS キャッシュポイズニング” や “MITM” と取り違える
  文脈は「負荷が高い」「可用性向上」というキーワードで、可用性を奪う典型的攻撃＝DDoS と結び付けるのがポイントです。

FAQ

解答の論理構成

1. 図4(4)の記述を確認します。

   “TLSの接続先サーバ名にはRFC 6066に基づいて、HTTPリクエストのcヘッダにはRFC 7230に基づいて、X-FQDNが指定される。”

2. RFC 7230 は HTTP/1.1 のメッセージ構文・ルーティングを定義しており、この RFC で “必須” と位置付けられているのが Host ヘッダです。Host ヘッダにはアクセス先 FQDN が入り、仮想ホストの識別やリクエストの転送先決定に使われます。
3. 図5(4) でも

   “当該マルウェアは、HTTPリクエストを送信する際、cヘッダにZ-FQDNを指定する。”
   とあり、Host ヘッダを偽装することで CDN が誤転送する “ドメインフロンティング攻撃” の解説になっています。

4. 以上より、c に入る語は RFC 7230 で規定され、FQDN を示すヘッダフィールド “Host” が妥当です。

誤りやすいポイント

• “SNI” と混同する
  TLS の拡張 “Server Name Indication” は RFC 6066 に基づき “接続先サーバ名” を示しますが、HTTP ヘッダではありません。
• “Origin” や “Referer” と取り違える
  いずれも RFC に登場しますが、リクエスト URL の生成元を示すヘッダであり、転送先 FQDN を示す用途ではありません。
• 大文字小文字の表記ゆれ
  HTTP ヘッダ名は慣例的に “Host” と先頭のみ大文字で書くため、全部小文字などにして減点されるケースがあります。

FAQ

解答の論理構成

1. 下線部①には「Y-CDN-U-FQDN を名前解決した IP アドレスを宛先とする通信を FW で拒否すると、複数の Web サイトが閲覧できなくなる影響があります」と記載されています。
2. 前段で「あるCDN（以下、CDN-Uという）が、X社内から頻繁にアクセスする他社のWebサイトの複数で利用されている」とあり、同一 CDN のエッジサーバを多数の Web サイトが共有していることが示唆されています。
3. CDN では 1 台のエッジサーバ（ひとつの IP アドレス）が、ホストヘッダや SNI によって複数の FQDN を“バーチャルホスト”として処理します。
4. したがって、その IP アドレスをファイアウォールで遮断すると、同じ IP 上に載っているすべての Web サイトへの通信が一律に拒否される結論になります。
5. 以上より、閲覧不能になる範囲は「Y-CDN-U-FQDN を名前解決した IP アドレスと同じ IP アドレスをもつ Web サイト」となります。

誤りやすいポイント

• 「Y-FQDN」のみ影響すると早合点し、CDN 共有 IP の存在を見落とす。
• “同じ FQDN”ではなく“同じ IP”で判定している点を読み落とす。
• 「FW で FQDN をブロック」と誤読し、拒否対象を IP アドレスではなくドメイン名だと思い込む。
• CDN が必ず専用 IP を割り当てると誤解し、影響範囲を過小評価する。

FAQ

解答の論理構成

1. 問題文では、ドメインフロンティング攻撃への対策として
   「FW 又はプロキシサーバを、アウトバウンド通信の復号及び高機能な通信解析ができるものに替え、dと HTTP リクエスト中のc ヘッダの値が一致していることを検証して、一致していなければ遮断する」という方針を示しています。
2. 直前の図4には
   「TLSの接続先サーバ名にはRFC 6066に基づいて、HTTPリクエストのcヘッダにはRFC 7230に基づいて、X-FQDNが指定される」
   とあり、ここで c が HTTP Host ヘッダであることがわかります。
3. ドメインフロンティングは、TLS ハンドシェイク中に送る SNI（Server Name Indication：TLSの接続先サーバ名）と、暗号化後に送る Host ヘッダの値を意図的に食い違わせる手口です。
4. よって、検証対象である d は「TLS ハンドシェイクで示された接続先サーバ名」、すなわち「TLSの接続先サーバ名」となります。

誤りやすいポイント

• d を「SNI」や「サーバ証明書のCN」など英語略称で書いてしまう。問題文は「TLSの接続先サーバ名」と日本語で表現しているため、そのまま引用する必要があります。
• Host ヘッダと比較する対象を「IPアドレス」と誤解するケース。ドメインフロンティングは SNI と Host の不一致を利用する攻撃です。
• 図4の記述を読み落とし、c が Host ヘッダであると気付かないまま解答を組み立ててしまう。

FAQ

解答の論理構成

1. 図7のシーケンスでは、認証サーバが「ST²)」を発行した後、 「XPC → GrWサーバ　ラベル：ST」とあり、STは直接サービス提供サーバ（GrWサーバ）へ送られます。
2. 表1の処理3も、「STを復号して検証し、問題なければ、アクセスを許可する。」と示し、STの検証主体はGrWサーバであることを明示しています。
3. 一方、認証サーバ側にはSTが再送信される経路がなく、本文中でF氏が
   「②STの偽造については、認証サーバ側で検知することができません」
   と指摘しています。
4. 以上より、STは発行後に認証サーバへ戻らないため、不正なSTであっても認証サーバは観測・検証できません。
5. よって解答は「STは認証サーバに送られないから」となります。

誤りやすいポイント

• TGTとSTの役割を混同し、どちらがどのサーバに提示されるかを取り違える。
• 「認証サーバがSTを作る＝常に検証もできる」と早合点し、通信経路を確認しない。
• 図7の矢印を見落とし、「XPC→認証サーバにSTが再送される」と誤読する。

FAQ

解答の論理構成

1. 問題文は、攻撃者が「奪取されたST」に対して「サーバ管理者アカウントのパスワードの総当たり攻撃」を行うと述べています。
   ――【問題文引用】「奪取されたSTに対してサーバ管理者アカウントのパスワードの総当たり攻撃が行われ…」
2. この攻撃は ST を入手した攻撃者の端末上で実施できるため、認証サーバへログイン試行を送信する必要がありません。
   ⇒ 失敗回数はサーバに記録されず、アカウントロック機能が発動しません。
3. したがって、「サーバ側でログイン連続失敗時のアカウントロック」を有効にしていても無意味である、という③の指摘になります。
   ――【問題文引用】「③サーバ側でログイン連続失敗時のアカウントロックを有効にしていても対策になりません」

誤りやすいポイント

• 「総当たり＝ログイン繰返し」と早合点し、オンライン攻撃だと思い込む。
  実際は ST を解析するオフライン攻撃。
• アカウントロックを“万能”と誤解し、ソースを問わず適用できると考えがち。
• Kerberos の ST が暗号化済みであることを理由に“総当たりは困難”と判断し、リスクを過小評価。

FAQ

解答の論理構成

1. 【問題文】の該当部分
   ― 表2 処理2
   「図8中の(3)の HTTP リクエスト中の e から SAML Request を取得する。」
2. 図8の(3)は、XPC → IDaaS 方向の「SAML Request を含む HTTP リクエスト」です。
   このリクエストは、処理1で「エンコード結果と IDaaS のログイン画面の URL を組み合わせて、リダイレクト先 URL を生成」しているため、SAML Request はリダイレクト先 URL に含まれます。
3. HTTP において URL 末尾の「?name=value」の形で付加される部分をクエリ文字列と呼びます。ここに SAMLRequest=... が格納されるのが標準的な HTTP Redirect Binding の仕様です。
4. よって e に当てはまるのは「ウ：クエリ文字列」です。

誤りやすいポイント

• cookie を選ぶと、ブラウザがサーバへ自動送信するヘッダ領域と混同していることになります。SAML Request は URL に直接載るため cookie ではありません。
• ボディを選ぶと、HTTP POST Binding と勘違いしたことになります。本問は Redirect（GET）Binding の流れです。
• リファラを選ぶと、参照元 URL を示すだけであり、SAML Request を格納する用途ではない点を見落としていることになります。

FAQ

解答の論理構成

1. 役割の確認
   • 【問題文】には「IDaaSの利用を提案します。多くのIDaaSでは…SAML認証をサポートしています。」とあり、IDaaSが SAML 認証の IdP（Identity Provider）であることが明示されています。
2. 署名者は IdP
   • SAML では、IdP が生成する SAML Response／アサーションに自らの秘密鍵でデジタル署名を付与し、SP（ここでは SaaS）が受信後にその署名を検証するのが基本仕様です。
3. 表2の文脈に当てはめる
   • 表2の処理4には「SAML Response に含まれるデジタル署名を検証することで、デジタル署名が f のものであること…を確認する。」と記載されています。
   • SaaS が検証する相手は、自身ではなく署名を付けた側、つまり IdP＝IDaaS です。
4. 解答選択
   • 解答群「ア：IDaaS」「イ：SaaS」「ウ：XPC」より、署名者である IDaaS が正答です。

誤りやすいポイント

• 「SaaS がサービス提供側だから署名者も SaaS」と誤解しやすい。実際には SaaS は署名“検証”側です。
• 「クライアント(XPC)から送られてくるので XPC が署名者」と考えてしまうミス。SAML Response は IdP から発行されるため、クライアントは署名を付けません。
• Kerberos のチケット発行者＝認証サーバという発想をそのまま SAML に当てはめられず、混乱しやすい。

FAQ

解答の論理構成

1. 【問題文】表2の処理4では
   「SAML Response に含まれるデジタル署名を検証することで、デジタル署名が f のものであること、及び SAML アサーションの g がないことを確認する。」
   と明記されています。
2. ここで行う検証は、 • デジタル署名の正当性確認
   • アサーションが改変されていないかの確認
   という 2 点です。改変を表す用語として最も適切なのが「偽造」です。
3. SAML アサーションは利用者の認証結果を示す重要なデータです。万一「偽造」されると、なりすましが成立し、SSO 全体の信頼性が失われます。
4. したがって「SAML アサーションの偽造がないことを確認する」という文章が成立し、g には『偽造』が入ります。

誤りやすいポイント

• 「改ざん」「改変」など類義語を入れてしまう
  → 原文では“アサーションの○○がない”と否定形で述べており、「偽造がない」という表現が自然です。
• 署名検証＝完全性確認とだけ考え、「欠落」「変更」などを選ぶ
  → 署名が正しくても攻撃者が自前で署名し直した場合は“偽造”にあたります。
• SAML の知識不足で認証・認可を混同し、「漏えい」や「重複」など的外れな単語を選ぶ。

FAQ

解答の論理構成

1. 【問題文】には、事前に共有すべき情報として
   「SAMLアサーションで用いる属性、図8中の処理hで用いるURL、図8中の処理i及び処理jにおいて必要なデジタル証明書」
   とある。
2. 表2「図8中の各処理の概要」を確認すると、
   • 処理1：
     「IDaaSに認証を要求する SAML Request を生成し…IDaaS のログイン画面の URL を組み合わせて、リダイレクト先 URL を生成する。」
     URL が直接登場するのは 処理1。したがって h＝1。
   • 処理3：
     「…SAML アサーションと、それに対するデジタル署名を含めた SAML Response の送信フォームを生成する。」
     署名生成には公開鍵証明書が必須。よってデジタル証明書が必要となるのは 処理3。
   • 処理4：
     「SAML Response に含まれるデジタル署名を検証することで…」
     署名検証にも公開鍵証明書が必要。したがって 処理4 でも証明書を用いる。
3. 以上より、 ・URL を用いる処理 → 1
   ・証明書を用いる処理 → 3 と 4
   が導かれ、【模範解答】の
   h：1／i：3／j：4
   が妥当であると確認できる。

誤りやすいポイント

• 表2を流れ図の順番（1→2→3→4）と結び付けず、メッセージ番号（図8の(1)〜(8)）と混同してしまう。
• 「証明書＝検証だけ」と思い込み、署名“生成”側（処理3）での証明書の必要性を見落とす。
• 処理1の説明文にある「URL」を見逃し、h に 2 を入れてしまうミス。

FAQ

解答の論理構成

1. 図9の前提
   【問題文】では、F氏が「Sサービス、GrW-G及びIDaaS-Gは、OAuth 2.0をサポートしています。」と説明し、さらに「OAuth 2.0を利用したサービス要求からスケジュール情報の取得までの流れは、図9のようになります。」と述べています。
   したがって、図9の3本のライフライン k〜m は、Sサービス・IDaaS-G・GrW-G のいずれかに対応すると分かります。
2. 流れ(1)・(2)に注目
   図9で「(1) サービス要求」を受け取るのは k です。利用者が最初にアクセスするのは日程調整を行う「Sサービス」です。
   また、表3の利用手順(1) でも「主催者は、Sサービスにアクセスする。」と明記されています。
   よって k = 「Sサービス」 ⇒ 解答群「ウ」に該当します。
3. 流れ(3)〜(8)に注目
   認可コードの発行やトークン応答を行うのは OAuth 2.0 の認可サーバ／トークンエンドポイントです。X社環境でこの役割を担うのは IDaaS-G です。
   図9で認可要求(3)を受け、トークン応答(8)を返すのが l であるため、l = 「IDaaS-G」 ⇒ 解答群「イ」と判断できます。
4. 流れ(9)・(10)に注目
   アクセストークンで保護リソース（スケジュール情報）を提供するのは GrW-G です。図9で「(9) 利用者情報の問合せ」を受ける m がこの役割に対応します。
   したがって m = 「GrW-G」 ⇒ 解答群「ア」に該当します。
5. 結論
   ・k＝ウ：「Sサービス」
   ・l＝イ：「IDaaS-G」
   ・m＝ア：「GrW-G」

誤りやすいポイント

• Sサービスを「リソースサーバ」と勘違いし、m にしてしまう。実際には Sサービスはクライアント（依頼元）でありリソースを持たない。
• IDaaS-G と GrW-G の役割を逆に読む。トークン発行は IDaaS-G、スケジュール提供は GrW-G である。
• OAuth 2.0 の一般的な図を暗記していても、問題固有の名称と正しく対応付けないと取り違える。

FAQ

解答の論理構成

1. 役割の整理
   • 図9の(1)～(8)を見ると、 ・(1)「サービス要求」を受け取る k は Sサービス（クライアント）
     ・(3)「認可要求」を受け取り、(7)(8) で「トークン要求／応答」を行う l は IDaaS-G（認可サーバ）
     ・(9)(10)「利用者情報の問合せ／利用者情報」を返す m は GrW-G（リソースサーバ）
     であることが読み取れます。
2. スケジュール取得処理の一般モデル
   OAuth 2.0では、クライアントがアクセストークンを用いてリソースサーバに API 要求を送るか、認可サーバがゲートウェイとなってリソースサーバを呼び出す2通りがあります。
   X社の構成は「認可サーバ＝IDaaS-Gが API ゲートウェイも兼ねる」方式で、次のような流れになります。
   (11) Sサービスは、取得したアクセストークンを添えて IDaaS-G(l) に「スケジュール取得要求」を送信
   (11)ʼ IDaaS-G はトークンを検証したうえで GrW-G(m) に API 呼び出し
   (12) GrW-G から返されたスケジュール情報を IDaaS-G → Sサービス へ転送
3. 解答群の照合
   行エは
   ・「スイムレーン l → m に向かう矢印『(11) スケジュール取得要求』」
   ・「スイムレーン k ← l 間に向かう矢印『(12) スケジュール情報』」
   と記述されており、上記のゲートウェイ方式と一致します。
   したがって図9中 n の正しい流れは 行エ です。

誤りやすいポイント

• 「アクセストークンを受け取ったクライアントが必ず直接リソースサーバへアクセスする」と早合点し、行ウ（k→l→k）を選んでしまう。今回は IDaaS-G が API ゲートウェイを兼ねるため、最初に l が動きます。
• l と m の役割を逆に読み取るミス。トークンエンドポイントを提供するのが IDaaS-G である点を手掛かりに確認する必要があります。
• 行ア・行イはレスポンスの戻り先が「利用者端末」になっており、Sサービス(k) を経由しないためシーケンス全体と整合しません。

FAQ

解答の論理構成

1. 問題文には
   「適切な実装であれば、図9中のoにおいて、stateパラメタを付与して送信し、図9中のpで送られてきたものと比較することで、攻撃を検知しているはずです。」
   とある。
2. state パラメタは OAuth 2.0 の認可“要求”時に付与し、認可“応答”で戻ってきた値と比較することで CSRF を検知するのが標準的な手順である。
3. 図9を見ると、認可要求を含む URL をブラウザに返す「(2) リダイレクト」が最初の“送信”に該当し、ここで state を付加する。
4. 認可サーバでの処理後、ブラウザ経由でクライアントに戻るのは「(5) リダイレクト」→「(6) 認可コード」である。図9では state を検証できるのはクライアントにコードが届く「(6) 認可コード」のタイミングである。
5. 以上より、 • o＝図9中の「(2) リダイレクト」
   • p＝図9中の「(6) 認可コード」
   となる。

誤りやすいポイント

• 「state を付けるのは認可要求だから (3)」と決めつけるミス
  図9では (3) はユーザ端末→認可サーバの通信であり、問題文が求める“付与して送信”主体はクライアント (k) なので (2) が正解。
• 「state を受け取るのはリダイレクトだから (5)」と誤判断
  (5) はブラウザが受け取る段階。クライアントが比較できるのは (6) でブラウザからクライアントへ届く時点。
• CSRF と XSS を混同し、nonce パラメタの概念と取り違えるミス

FAQ

解答の論理構成

1. 問題文では、スマホアプリ経由で認可コードが奪取される恐れがあるための対策として次の記述があります。
   ――引用――
   「Sサービスのスマホアプリでランダムな検証コードとその値を基にしたチャレンジコードを作成して、そのチャレンジコードを認可要求に追加し、検証コードをトークン要求に追加します。二つのコードを検証することで、検証コードを知らない攻撃者からのトークン要求を排除できます。この仕組みは、qとして標準化されています。」
   ――ここまで――
2. ランダムな“検証コード（code verifier）”と、それを変換した“チャレンジコード（code challenge）”を用い、トークン取得時に両者を照合してコード横取りを防ぐ仕組みは OAuth 2.0 の拡張仕様「Proof Key for Code Exchange（PKCE）」で定義されています。
3. 解答群を確認すると、該当する選択肢は「ウ：PKCE（Proof Key for Code Exchange）」のみです。
   したがって q の正解は「ウ」となります。

誤りやすいポイント

• 「ASLR」のように名称に“ランダム”が含まれる対策と混同する。ASLR はメモリ配置をランダム化する OS レベルの緩和策であり、OAuth とは無関係です。
• 「EIAM」「SCIM」を“ID 関連だから適切”と早合点する。どちらも IAM やアカウント同期の枠組みであり、認可コードの盗聴対策を規定した仕様ではありません。
• PKCE を「ネイティブアプリ専用」と思い込み、Web ブラウザ利用時には不要だと誤解するケース。実際には公開クライアント全般で有効です。

FAQ

解答の論理構成

1. 連携要件の確認
   【問題文】では、 “T社投稿サイトの認証サーバを用いた認証機能、及びT社投稿サイトの投稿サーバへの自動投稿機能をX社動画サーバに追加したい”
   と明記されています。
   したがって、 • 認証は “T社投稿サイトの認証サーバ” が担当
   • “X社動画サーバ” はサービス（クライアント）側
   • 投稿（リソース操作）は “T社投稿サイトの投稿サーバ” が担当
   という3者構成になります。
2. 図10 の流れと各ノードの役割対応
   図10 には利用者端末の右側に3つの空欄 r・s・t が並び、下段に
   “APIを使った “動画の概要” の投稿”
   という矢印が r → t に描かれています。
   これは【問題文】で説明された「動画投稿時に “動画の概要” を自動投稿」動作に該当し、サービス側（X社動画サーバ）からリソースサーバ（T社投稿サイトの投稿サーバ）への API 呼び出しであると判断できます。
3. 各空欄への具体的な字句の当てはめ
   (1) r：最初に “サービス要求” を受け取り、認可コードを取得し、最後は投稿 API を呼び出す――これは X社側の Web アプリ、すなわち “X社動画サーバ” です。
   (2) s：“認証要求” を受け取り “ログイン処理” を行い “トークン応答” を返す――OIDC における Authorization Server であり、問題文中の “T社投稿サイトの認証サーバ” に一致します。
   (3) t：投稿 API の終点となる “T社投稿サイトの投稿サーバ” が最適です。
4. 解答
   r＝“オ：X社動画サーバ”
   s＝“エ：T社投稿サイトの認証サーバ”
   t＝“ウ：T社投稿サイトの投稿サーバ”

誤りやすいポイント

• OIDC の “クライアント” と “認証サーバ” を逆に読み取って r と s を取り違える。
• 投稿 API の宛先を “X社動画サーバ” と勘違いし、t を誤答する。
• “IDaaS-G” や “Sサービス” は設問 〔企画チームからの要望〕 とは無関係であることを見落とす。

FAQ

解答の論理構成

1. 【問題文】には
   「F氏：認可コードフローの場合、IDトークンは、図10中のuで送付されます。」
   と明記されています。
2. 図10の凡例を見ると、(8) の矢印には
   「(8) トークン応答」
   と記載されています。
3. OpenID Connect の認可コードフローでは、クライアント（ここでは「r」＝X社動画サーバ）がトークンエンドポイントに対してトークン要求を出した後、トークン応答で「IDトークン」と「アクセストークン」などが返却されるのが標準仕様です。
4. したがって、IDトークンが送付されるタイミング＝「トークン応答」に該当する図10中の番号は (8) となります。

誤りやすいポイント

• (5) リダイレクトと混同する
  リダイレクトでは「認可コード」しか渡されません。IDトークンは含まれないので要注意です。
• OIDC と OAuth 2.0 の役割を誤解する
  OAuth 2.0 は“認可”の枠組み、OIDC はそれに“認証（ID トークン）”を追加する拡張です。フローのどこで各トークンが出現するかを区別しましょう。
• IDトークンとアクセストークンを同一視する
  IDトークンは“利用者を識別する情報”、アクセストークンは“API 呼び出しの権限”です。図10では両者が同じトークン応答でまとめて返却される点を押さえてください。

FAQ

解答の論理構成

1. 【問題文】では、IDトークンについて
   “ヘッダ、ペイロード、署名は、それぞれvでエンコードされます。”
   と明記されています。
2. IDトークンは JSON Web Token（JWT）形式であり、JWT 仕様（RFC 7519）では
   “Header, Payload, Signature are encoded individually with Base64url Encoding”
   と規定されています。
3. よって、JWT の各部をエンコードする方式＝v は “base64url” が正解です。
4. 解答群から “base64url” に該当する記号は「イ」であるため
   v：イ となります。

誤りやすいポイント

• Base64 と base64url の混同
  • “+/” を “-_” に置換し、パディング “=” を省略するのが base64url ですが、単なる Base64 と誤解しやすいです。
• UTF-8 や ROT13 との取り違え
  • UTF-8 は「文字コード」、ROT13 は「単純換字式暗号」であり、エンコード形式としては文脈が異なります。
• JWT の「全体をまとめて一度だけエンコードする」との誤認
  • 実際には “ヘッダ・ペイロード・署名を個別に base64url エンコードし、ピリオドで連結” が正しい手順です。

FAQ

解答の論理構成

1. 【問題文】では、OIDC ハイブリッドフローにおける nonce 値の扱いについて
   「まず、nonce値を生成し、wに含めて送信します。」
   と記載されています。nonce は RP（X社動画サーバ）が OP（T社投稿サイト認証サーバ）へ送る “認証リクエスト” に格納するのが OIDC の仕様です。したがって w には「認証要求」が入ります。
2. 続けて
   「次に、送られてきたxに含まれるnonce値を検証することで、攻撃者によるIDトークンの不正利用を防ぐことができます。」
   とあります。OP から RP へ戻るメッセージで nonce が含まれるものは ID トークンだけです。よって x には「IDトークン」が入ります。
3. 以上より
   w：認証要求
   x：IDトークン
   が妥当となります。

誤りやすいポイント

• 「state パラメタ」と混同して、nonce を “リダイレクト” や “認可コード” に含めると誤解しやすい。nonce は ID トークンと照合 するため認証要求に入れる必要があります。
• ID トークンとアクセストークンを混同しがち。アクセストークンには nonce が入らないため、ここで検証対象となるのは ID トークンです。
• OIDC と OAuth 2.0 の用語差異を意識せず「認可要求」と「認証要求」を取り違えるケースが多い。

FAQ