全体像（舞台設定）
S社（従業員10名のベンチャー）は、写真等のファイル共有・URL共有・メッセージ・「いいね」機能を備えたWebサービス（Sサービス）を運営。ユーザ（S会員）はログイン後に自分のフォルダへアップロードし、URLで他者と共有できます。セキュリティ診断は外部企業に随時依頼しています。
直近の診断で、「自前のID/パスワード認証（S認証モジュール）より多要素認証にした方がよい」と助言され、S社はT社のSNS（Tサービス）とID連携する方針に。新規会員の登録・認証はTサービス連携、多要素認証を活かし、既存会員は当面S認証モジュールを継続、という“移行期の併用”設計です。
誰が何をする？（三者と役割）
ID連携にはOAuth 2.0 Authorization Code Grantを採用。登場人物は3者：
-
利用者（S会員登録希望者／既存S会員）
-
Sサービス（クライアント/リソース利用側）
-
Tサービス（認証・認可を提供するSNS、アカウント名＝T-IDを持つ）
Tサービスで取得可能な権限は「いいね」「メッセージ」「代理投稿」「プロフィール取得」など（図3）。Sサービスは“将来使うかも”という想定で全権限を要求する設計を最初は考えています。
どう流れる？（OAuthのシーケンスの読み方）
図2の流れは要点だけ押さえればOK。
-
SサービスがTサービスに「認可」を要求 → 2) 利用者はTサービスで認証し、権限付与を確認 → 3) TサービスがSサービスに「認可コード」を返す → 4) Sサービスはそのコードで「アクセストークン」を取りに行き、成功したらT-ID（Tのアカウント名）を問い合わせて受け取る。初回利用時はこのT-IDをSサービス内に登録、2回目以降は登録済みT-IDと一致確認を行う（＝これが連携後の“認証の要”）。
本文の“a/b/c/α～”の意味づけ（よくある混乱ポイント）
本文では、図2の参加者やメッセージの誰が誰に相当するかを文字（a, b, c, 「…）で表しています。実質は上の三者とシーケンス対応の当てはめ問題で、「SがTにこう要求し、利用者がこう許可する」という因果が読み取れればOK。設問で問われますが、本文理解としては「Sが要求→Tが認証・権限確認→Sがトークン取得→SがT-IDを取得」という大きな骨格を掴めば十分です。
一つ目の問題：攻撃シナリオ（トラップサイト→不正な連携状態）
Y氏が指摘した一つ目の問題は**“利用者が気づかぬうちに攻撃者の連携状態を成立させる”**タイプ。利用者が攻撃者の用意したサイトにアクセスすると、OAuthの一部が勝手に進み（図4のシーケンスX）、その後に利用者がSサービスへ戻って通常操作（例：ファイルアップロード）したとき、実は攻撃者の権限が紐づいた状態なので、攻撃者にダウンロードされ得る、という筋立てです。
対策：stateパラメータで“同一セッション性”を検証
RFC 6749推奨のstateパラメータを用い、Sサービスが認可要求時に推測困難なstateを付与し、戻ってきた応答に含まれるstateが同じセッション由来かを厳密に照合。合わなければフローを打ち切る、というCSRF対策の一種です。本文も「stateを付けて送り、戻りで“同一セッションか”確認」と明示しています。
二つ目の問題：権限（スコープ）が最小化されていない
最初の実装案は「将来使うかも」で全権限を要求していましたが、これは最小権限の原則に反します。Y氏は必要最小限の権限だけに絞るよう指摘。本文では「要求権限を一つだけにした」とあります。OAuth連携では“今まさに必要なものだけ”要求するのが基本です。
三つ目の問題：Tサービス側に深刻な脆弱性が出たら？
外部IdP（Tサービス）に重大脆弱性が見つかったときのBCP（継続/切替）を決めていないのはリスク。本文ではID連携を一時停止しS認証モジュールのみで認証する運用に。ただしこの場合、S認証モジュールにID/パスワードを登録していない会員は使えなくなるため、対象者向けに代替策（例：一時アカウント付与等）を検討することになります。
「連携後の“認証”はどう成り立つ？」（本文の核心）
全面移行後はSサービス自身は直接パスワード認証しません。代わりにTサービスで認証済みの“誰か”が、S側に登録済みのT-IDと一致するかを確認することで“そのS会員本人だ”と扱います。要は、T-IDの照合がS側の利用者認証のコアになる、という考え方です。
ここが読み取りのコツ（本文の狙い）
-
狙い1：OAuth実装の実務感覚
フローのどこで何を要求・検証し、初回に何を保存（T-ID）し、以後どう照合するかを“運用手順”として理解させる。 -
狙い2：セキュリティ考慮点
ログインCSRF等をstateで防ぐ、スコープ最小化、外部IdPの障害/脆弱性時の切替設計（可用性・BCP）など。 -
狙い3：連携後の“認証”の本質
「Tで認証されたその人＝Sで登録済みT-IDの持ち主か」を突き止める照合設計。
