シングルサインオンは「1回のログインで複数のサービスを使える」仕組みですが、要点は便利さではなく役割の分離です。認証するのは1か所だけで、利用先のサービスはその結果を受け取って信じる。パスワードは利用先へ渡りません。ここを掴むと、検証項目も攻撃点も自然に出てきます。
登場人物は2つです。認証する側（利用者の資格情報を持ち、本人確認を行う）と、利用する側（業務のサービス本体）。両者の間を行き来するのは、「この人は確かに本人だ」という署名付きの主張です。主張は利用者のブラウザを経由して渡されるので、途中で作り替えられていないかを受け取り側が確かめる必要があります。
動きで見る
2つ目のサービスを開くときは、認証する側に既にセッションがあるので、本人確認の画面は出ずに主張だけが発行されます。これが「1回のログインで済む」の中身です。各サービスが個別に認証しているのではありません。
「利用先にもパスワードが渡っている」と考えると全部ずれます。渡るのは結果の主張だけ。だから利用先が侵害されてもパスワードは漏れませんが、逆に認証する側が破られると全サービスが破られます。利便性の裏でリスクが1か所に集まる——この裏表が設問の定番です。
受け取り側が確かめること
検証する項目
- 署名：信頼している発行元の鍵で検証できるか
- 宛先：自分宛の主張か（他サービス宛の使い回しを弾く）
- 有効期限：期限内か。時計のずれも考慮する
- 使い回し：一度使った主張を再提示されていないか
抜けると起きること
- 署名を見ない → 偽の主張で誰にでもなれる
- 宛先を見ない → 別サービス向けの主張を流用される
- 期限・使い回しを見ない → 盗んだ主張を後から再利用される
穴埋めでは「認証する側」「利用する側」を、その問題の構成図の名前で答えさせます。役割で押さえておけば当てはめるだけです。また、認証と認可を分けて書くと強い答案になります。この仕組みが運ぶのは「誰であるか」で、「何をしてよいか」は利用先が自分で決めます。ここを混ぜると、権限設計の設問で失点します。
集約したからこそ、そこを厚くする
認証が1か所に集まるということは、そこを守れば全体が守れるということでもあります。だから設問の対策側は多要素認証・ログイン試行の監視・管理者権限の分離といった、認証する側を厚くする方向に寄ります。「便利になった代わりに何を厚くするか」を書ければ十分です。