はじめに
Webサービスや業務システムが増えるにつれ、
「ログインが多すぎる問題」 は深刻になりました。
- サービスごとにID・パスワード
- パスワード使い回し
- 退職者アカウントの消し忘れ
これらをまとめて解決する仕組みが SSO（Single Sign-On） です。
SSOの定義
SSO（Single Sign-On） とは、
一度の認証で、複数のサービスへ再認証なしでアクセスできる仕組み
のことです。
ポイントは
❌ パスワードを共有する
⭕ 認証結果（トークン）を信頼関係で共有する
基本構成（必ず押さえる）
SSOは必ず次の3者で構成されます。
| 役割 | 説明 |
|---|---|
| ユーザー | ログインする人 |
| IdP（Identity Provider） | 認証を行う中核 |
| SP（Service Provider） | 実際のサービス |
認証フロー（概念）
- ユーザーがSPへアクセス
- 未認証 → IdPへリダイレクト
- IdPで認証（パスワード・生体・MFA）
- 認証済み証明（トークン）を発行
- SPがトークンを検証しログイン完了
👉 SPは「本人確認」を自分でやらない
SSOで使われる主要プロトコル
1. SAML（Security Assertion Markup Language）
- XMLベース
- 企業内SSOで長年使用
- 非常に枯れている
👉 安定だが、実装は重め
2. OAuth 2.0（※本来は認可）
- APIアクセス制御が目的
- 認証そのものではない
- 「ログインに使う」のは誤用になりがち
3. OpenID Connect（OIDC）
- OAuth 2.0 を拡張
- 認証用途に正式対応
- Web / モバイルの主流
👉 現代SSOのデファクトスタンダード
4. Kerberos
- チケットベース
- Active Directory環境で使用
- オンプレ・社内向け
なぜSSOはセキュリティを「強く」するのか
ユーザー視点
- パスワード入力回数が激減
- フィッシング耐性が向上
- ログイン体験が高速
管理者視点
- アカウント管理の一元化
- 退職者の即時アクセス遮断
- MFA・条件付きアクセスを集中管理
👉 セキュリティとUXを同時に改善
SSOの落とし穴（重要）
1. 単一障害点（SPOF）
- IdP障害 = 全サービス停止
👉 冗長化・可用性設計必須
2. トークン管理ミス
- 有効期限が長すぎる
- Refresh Tokenの扱いが雑
- クライアント側保存が甘い
👉 SSO事故の9割はここ
3. ログアウト問題
- 全サービスからログアウトさせるのは難しい
- 「Single Logout」は実装が複雑
よくある誤解
| 誤解 | 実際 |
|---|---|
| SSO = パスワード共有 | ❌ |
| OAuth = 認証 | ❌ |
| SSOは便利だが危険 | ❌（設計次第） |
| 最新実装が最強 | ❌（枯れた方が強い） |
まとめ
- SSOは認証の集約によるUX・セキュリティ向上策
- 中核は IdP
- 主流は OpenID Connect
- 成功の鍵は 枯れた実装 + MFA + 運用設計
認証は「攻める場所」ではない
失敗しない設計を選ぶ場所である