SSOとは何か？概要・認証プロトコル・設計・運用までを網羅する完全ガイド
エバープレイ編集部SSOとは：概要と本質
SSO（Single Sign-On、シングルサインオン）は、一度の認証操作で複数のシステムやサービスへアクセスできるようにする仕組みです。ユーザーは複数のアプリケーションごとに都度ログインする必要がなく、利便性の向上と認証管理の一元化が図れます。企業のイントラネット、クラウドサービス群、モバイルアプリ、SaaSなど、さまざまな環境で採用されています。
SSOが解決する課題
- ユーザーの利便性向上：パスワード入力の回数を減らし、ログインの摩擦を軽減。
- 運用負荷の低減：認証ポリシー、パスワードポリシー、MFA を中心管理できる。
- セキュリティ改善：パスワードの分散管理によるリスクを減らし、中央でのログ監査や多要素認証の適用が容易に。
- ユーザーライフサイクル管理の効率化：一括作成・削除や属性同期（プロビジョニング）が可能に。
代表的な技術スタックとプロトコル
- SAML 2.0：企業のWeb SSOで長く用いられているXMLベースの標準。IdP（Identity Provider）とSP（Service Provider）間で署名付きアサーションを交換する。
- OAuth 2.0：認可フレームワーク。リソースアクセスの許可に使われ、認証目的には単体では不十分。
- OpenID Connect (OIDC)：OAuth 2.0 を拡張し「認証」を扱う仕様。IDトークン（JWT）でユーザー情報を提供する。
- Kerberos / SPNEGO：Windowsドメインでの統合認証（Integrated Windows Authentication）。ネットワークレベルでのチケットを用いる。
- LDAP：厳密には認証プロトコルではなくディレクトリサービス。ユーザー属性の参照や認証連携に使われることが多い。
- SCIM：ユーザーのプロビジョニング（自動作成・更新・削除）を標準化するAPI仕様。
典型的なSSOのアーキテクチャ
一般的な構成要素は次のとおりです。
- Identity Provider（IdP）：ユーザーの認証を行い、認証情報や属性を発行する中心的サービス（例：Azure AD、Okta、Keycloak、ADFS）。
- Service Provider / Relying Party：IdPの発行した認証情報を検証し、サービスの利用許可を行うアプリケーション。
- ユーザーエージェント（ブラウザ・ネイティブアプリ）：認証フローを媒介する。
- プロビジョニング連携（SCIM）やディレクトリ同期（AD Connectなど）：アカウントのライフサイクル管理。
代表的なフロー（ステップ解説）
SAML 2.0（SP-initiated）の基本フロー
- ユーザーがSPのサービスにアクセス。
- SPが認証されていないことを検知し、IdPへ認証リクエストをリダイレクト。
- IdPでユーザーが認証（または既に認証済みで即応答）。
- IdPがSAMLアサーション（署名付き）をユーザー経由でSPに返送。
- SPはアサーションの署名・発行者・有効期間などを検証し、セッションを作成してアクセスを許可。
OpenID Connect（Authorization Code Flow）の基本フロー
- ユーザーがRelying Party（RP）へアクセス。RPは認可エンドポイントへリダイレクト（scope に "openid" を含める）。
- ユーザーがIdPで認証・同意すると、Authorization Code がRPに返される。
- RPはAuthorization Codeを使ってToken Endpointへ交換し、IDトークン（JWT）とアクセストークンを取得。
- RPはIDトークンの署名、nonce や aud／iss／exp の検証を行い、ユーザーをログインさせる。
- モバイルやパブリッククライアントではPKCEを利用してAuthorization Codeを保護する。
導入時の設計上の注意点・ベストプラクティス
- HTTPSの徹底：すべてのエンドポイント、リダイレクト、トークン通信はTLSで保護する。
- 既存の認証基盤（AD等）との連携戦略を策定：リアルタイム同期 vs バッチ同期、SCIMの活用。
- トークン管理：アクセストークンは短寿命、リフレッシュトークンは安全に保管（可能ならサーバ側に保持）し、リフレッシュトークンのローテーションを検討。
- 署名と鍵管理：JWKsを用いた公開鍵取得と定期的な鍵ローテーション、署名方式の確認（RS256等）。
- セッション管理：セッションクッキーのSecure/HttpOnly/SameSite属性設定、セッションタイムアウト、セッション再検証ポリシー。
- MFAの適用：リスクベースの条件付きアクセスを導入し、重要操作に対しては多要素認証を必須化。
- 最小特権の原則：token scope/claims は必要最小限に限定。
- ログアウト（SLO）の扱い：完全なシングルログアウトは難しい。フロントチャネル・バックチャネル方式の限界と実装互換性を理解する。
- クライアント種類に応じたフロー選択：機密クライアント（Webサーバ）にはAuthorization Code、公開クライアント（SPA, モバイル）にはPKCEを併用。
セキュリティ上の注意点（詳細）
- トークン検証：iss（issuer）、aud（audience）、exp/nbf、署名、一意のnonceやstateの検証を必ず実施。
- Redirect URIの厳格管理：ワイルドカードや許可されていないリダイレクト先を許容しない。
- CSRF対策：認可リクエストにはstateパラメータを使用し、サーバで検証する。
- XSS対策：トークンやID情報をクライアントサイドで保管する場合はXSSリスクを考慮。可能ならサーバ側セッションを選択。
- リフレッシュトークンの保護：SPAではリフレッシュトークンの長期保管は避け、可能なら短寿命トークン＋回復手段を採用。リフレッシュトークン回転と不正検出を利用。
- 署名アルゴリズムの安全性：対称鍵より公開鍵暗号（RS256等）での署名検証を推奨。
運用上の考慮点
- 可用性と冗長化：IdPが単一障害点にならないよう冗長化とフェールオーバーを設計。
- モニタリング／監査：ログイン試行、異常なトークン発行、権限昇格などを監視しアラート化。
- 鍵のローテーションと影響範囲のテスト：公開鍵（JWK）をローテーションする際の互換性を確保。
- プライバシーと同意：ユーザー属性を他サービスへ提供する際は同意管理や最小開示を検討。
- コンプライアンス：GDPR・個人情報保護法などの規制対応。ログやトークンに個人情報を含めない検討。
よくある課題と対策
- SSO後の権限管理（認可）は別：SSOは「誰が誰であるか」を保証するのみで、アクセス制御（Role/ACL）は各サービスで適用する必要がある。属性（groups、roles）連携で改善する。
- 完全なシングルログアウトが困難：すべてのクライアントがSLOをサポートしないため、部分的なログアウトや短いセッションTTLでカバーする。
- 異なるプロトコル間の橋渡し：古いアプリがSAMLのみ、新しいアプリがOIDCのみの場合、IdPのブリッジ機能（プロトコル変換）やプロキシが必要。
- ユーザー名衝突や属性の不一致：正規化やマッピングルール、フェデレーション時の名前識別子（NameID／sub）の設計が重要。
モダンなトレンド
- Passwordless（WebAuthnなど）とSSOの組合せ。
- 条件付きアクセス／ゼロトラスト（デバイス状態・ネットワーク・場所に基づくポリシー適用）。
- Identity as a Service（IDaaS）の普及：Okta、Azure AD、Google IdentityなどクラウドIdPの採用増。
- OpenID Connect の普及：API連携やモバイルアプリでの標準的な認証方式としての定着。
- SCIMによる自動プロビジョニングとアクセスライフサイクルの自動化。
導入のための実践的なステップ
- 要件定義：カバレッジするアプリ、必要な属性、MFA要件、ログアウト要件を整理。
- IdP選定：既存環境との親和性、運用負荷、コスト、サポートプロトコルを比較。
- Pilot：影響の小さいアプリで試験導入し、フローと障害時の挙動を確認。
- 拡張展開：段階的にアプリを移行し、プロビジョニング・解除の自動化を進める。
- 運用と教育：サポート体制、ユーザー向けFAQ、障害対応手順を整備。
まとめ
SSOは利便性とセキュリティの両面で大きなメリットをもたらしますが、導入・運用にあたってはプロトコル選定、トークン管理、ログアウト戦略、プロビジョニング、人材・運用体制など多面的な検討が必要です。適切な設計とベストプラクティスに従うことで、ユーザー体験を改善しつつ、セキュリティを担保したID基盤を構築できます。
