午前I問題

外部サービスとの連携におけるアイデンティティ管理の一般原則に関する記述のうち、適切なものはどれか。

ア）外部の認証プロバイダに認証を委任することで、自社のサービスは一切のなりすましリスクから解放される　イ）複数の異なるIDプロバイダから同一のメールアドレスが提供された場合、そのメールアドレスのみを根拠にアカウントを自動的に統合してよい　ウ）外部IDプロバイダの障害時に自社サービスへログインできなくなる可用性リスクは、認証委任の設計段階で考慮すべき事項である　エ）OAuth2のアクセストークンは、ユーザーの本人性を保証するものであり、ID連携における認証（Authentication）の主目的で発行される

午前I の解答・解説を見る

正解： ウ

解説：

  • ア）不正解。外部プロバイダへ認証を委任しても、連携部分の実装不備（トークン検証漏れ等）や、外部プロバイダ自身のアカウント侵害によるなりすましリスクは残ります。委任は責任の一部移転であって、リスクの消滅ではありません。
  • イ）不正解。メールアドレスは詐称や再利用（退職者のメールアドレスが別人に再割当てされる等）の可能性があるため、メールアドレスのみを根拠とした自動アカウント統合は、なりすましによるアカウント乗っ取りの危険があります。
  • ウ）正解。外部IDプロバイダに認証を一本化すると、そのプロバイダが障害・メンテナンス中の場合、自社サービスへのログイン手段が失われる可用性リスクが生じます。代替ログイン手段の用意や複数プロバイダ対応など、設計段階での考慮が必要です。
  • エ）不正解。アクセストークンはAPIリソースへのアクセス権限（認可、Authorization）を表すものであり、ユーザーの本人性を保証する認証情報ではありません。認証情報としてはOIDCのIDトークンが該当します。この混同はOAuth2/OIDCの頻出の誤解です。

午前II問題

ソーシャルログイン（OAuth2/OpenID Connectを用いた外部IDプロバイダによる認証連携）のセキュリティリスクに関する記述のうち、最も適切なものはどれか。

ア）ソーシャルログインでは、外部IDプロバイダのアカウントが攻撃者に乗っ取られても、自社サービス側のアカウントには一切影響が及ばない　イ）複数のソーシャルログインプロバイダ（例：Google、Facebook）を並行して許可し、かつメールアドレスを名寄せキーとしてアカウントを自動統合する実装は、一方のプロバイダでメールアドレスが検証されていない場合、アカウント乗っ取りを許す脆弱性となり得る　ウ）OpenID ConnectのIDトークンは署名を検証しなくても、発行元（issuer）を信頼していればなりすましのリスクはない　エ）ソーシャルログインを導入すると、自社でパスワードを管理する必要がなくなるため、アカウントの不正利用対策は不要になる

午前II の解答・解説を見る

正解： イ

解説：

  • ア）不正解。外部IDプロバイダのアカウントが乗っ取られると、そのIDで認証している自社サービスにも攻撃者がログインできてしまいます。ソーシャルログインは認証を委任しているため、委任先の侵害は自社サービスへも波及します。
  • イ）正解。あるプロバイダがメールアドレスの所有権を検証せずに登録を許す実装であった場合、攻撃者は被害者のメールアドレスを名乗って別プロバイダにアカウント登録し、名寄せキー（メールアドレス一致）を悪用して被害者の既存アカウントに不正アクセスできる可能性があります。これは実際に複数のOAuthベンダー連携で報告された脆弱性パターンです。
  • ウ）不正解。IDトークンはJWT形式で署名されており、RP（依拠当事者）は署名検証・issuer検証・audience検証・有効期限検証を必ず行う必要があります。署名検証を省略すると、偽造されたIDトークンによるなりすましが可能になります。
  • エ）不正解。パスワード管理が不要になっても、セッション管理、アカウント連携解除、複数プロバイダの名寄せ、トークンの適切な検証など、別種の不正利用対策は引き続き必要です。

午後問題

コミュニティサービスを運営するF社は、自社サービスへの新規登録・ログインの利便性向上のため、Google・Apple・LINEの3つのソーシャルログインをサポートしている。実装では、いずれかのプロバイダから返却されたIDトークン内のメールアドレスを基準に、既存アカウントとの照合を行い、一致すればそのアカウントにログインさせる仕様となっていた。

ある日、利用者から「登録した覚えのないLINEアカウントで自分のアカウントにログインされた形跡がある」との問い合わせがあった。調査の結果、以下が判明した。

  • 被害者はもともとGoogleアカウントでF社サービスに登録していた
  • 攻撃者は、被害者のメールアドレスを認識した上で、そのメールアドレスを名乗る新規LINEアカウントを作成した（LINEはメールアドレス登録時にメール確認リンクのクリックを必須としない設定が利用可能であった）
  • 攻撃者がそのLINEアカウントでF社にログインしたところ、メールアドレス一致により被害者の既存アカウント（Google連携アカウント）に自動的にログインできてしまった

設問1

本事例でアカウント乗っ取りが成立した技術的な原因を説明しなさい。（150字程度）

設問1の解答・解説を見る

正解例： F社の実装は、IDプロバイダから提供されたメールアドレスの一致のみを根拠にアカウントを自動照合・ログインさせていた。LINE側でメールアドレスの所有権確認（メール確認リンクのクリック等）が必須でない設定であったため、攻撃者は被害者のメールアドレスを検証なしに自称してLINEアカウントを作成でき、その未検証のメールアドレスを使って被害者の既存アカウントへのログインが成立してしまった。

解説・採点基準（計15点）：

採点項目キーワード配点
メールアドレス一致のみでの自動照合の問題点名寄せキーの単純一致依存6点
LINE側のメール未検証という要因メールアドレス所有権未確認・確認リンク省略6点
因果関係の説明未検証メールを使った乗っ取り成立の流れ3点

部分点： 原因の一部（メール一致依存 or メール未検証）のみ説明→8点。

設問2

F社が講じるべき再発防止策を2つ提案しなさい。（150字程度）

設問2の解答・解説を見る

正解例： 1つ目は、IDトークンに含まれる email_verified クレームを確認し、値が真（検証済み）である場合のみメールアドレスによる自動照合を行うよう実装を修正する。2つ目は、メールアドレスの一致による自動アカウント統合を廃止し、初回連携時に既存アカウントへの追加連携を明示的な確認（既存アカウントのパスワード入力や確認コード送付等）を経て行う方式に変更する。

解説・採点基準（計15点）：

採点項目キーワード配点
email_verifiedクレームによる検証検証済みメールのみ照合対象とする6点
自動統合の廃止・明示的確認への変更既存アカウントへの明示的リンク確認6点
実装としての具体性実装可能な対策として記述3点

部分点： 対策を1つのみ提案→8点。

重要キーワード

用語説明
OAuth2 / OIDCソーシャルログインの基盤となる認可・認証プロトコル。OIDCのIDトークンがユーザーの本人性を表現する
ソーシャルログインGoogle・Apple・LINE等の外部IDプロバイダの認証を借用してサービスにログインする仕組み。認証委任のリスクを伴う
email_verifiedクレームOIDCのIDトークンに含まれる、メールアドレスがプロバイダによって所有権検証済みかを示すブール値。名寄せ・自動照合の安全性判断に不可欠
アカウント名寄せ（Account Linking）複数の認証手段・IDプロバイダを同一アカウントに紐づける処理。単純な属性一致による自動統合はなりすましリスクを伴う
多要素認証（MFA）ソーシャルログインの委任先アカウントが乗っ取られるリスクを軽減するため、IDプロバイダ側でのMFA有効化が推奨される
認証の委任（Delegated Authentication）自社で認証処理を行わず外部IDプロバイダに委任する方式。可用性・信頼境界・属性検証の設計を要する

まとめ

  • 午前I視点： 認証委任はリスクの消滅ではなく移転・共有であるという原則、OAuth2アクセストークンとOIDC IDトークンの役割の違い（認可 vs 認証）が基礎として問われる。
  • 午前II視点： ソーシャルログインの実務的な脆弱性は「属性（特にメールアドレス）の単純一致による自動照合」に起因することが多く、email_verifiedクレームの確認有無が急所となる。
  • 午後視点： アカウント乗っ取りの原因を「未検証属性への依存」として特定し、クレーム検証の徹底と明示的なアカウント統合フローへの変更を具体的に提案できるかが採点ポイント。