SSO（シングルサインオン）とは、一度の認証（ログイン）で、複数のクラウドサービスや社内システムを続けて利用できる仕組みです。利用者はサービスごとにID・パスワードを入力する手間から解放され、情シスはID管理を1か所に集約できます。一方で、認証基盤が突破されると「すべての扉が一度に開く」ため、設計と運用には相応の注意が要ります。
本記事では、SSOを初めて担当する情シスの方に向けて、仕組み・代表的な方式・導入のメリットと落とし穴を、実務目線で整理します。
- SSOの基本的な定義と、なぜ求められるのか
- SAML / OpenID Connect など主要な実現方式の違い
- 導入メリットと、見落としがちなリスク・運用の勘所
SSOとは何か？（1文でいうと）
SSOとは、信頼できる1つの認証基盤（IdP＝アイデンティティプロバイダー）で本人確認を済ませ、その結果を各サービス（SP＝サービスプロバイダー）が受け取ることで、サービスごとの再ログインを不要にする仕組みです。
ポイントは「パスワードを各サービスに配って回る」のではなく、認証結果（アサーションやトークン）を安全に受け渡す点にあります。各サービスはパスワードそのものを持たず、IdPからの「この利用者は本人で間違いない」という署名付きの証明を信頼します。
なぜSSOが必要なのか？
背景には、業務で使うSaaS・クラウドサービスの急増があります。サービスごとにID・パスワードが増えると、利用者は使い回しや単純なパスワードに流れやすく、情シスは退職者のアカウント削除漏れやパスワード管理に追われます。
SSOはこの「ID爆発」を、認証の入口を1つに束ねることで緩和します。利用者の利便性と、管理側のガバナンス（誰が・どのサービスを使えるか）の両立が主な狙いです。
SSOの主な方式（仕組みの種類）
実現方式はいくつかありますが、現在のクラウド連携では「フェデレーション方式」が主流です。代表的なプロトコルは次のとおりです。
| 方式 | 概要 | よく使われる場面 |
|---|---|---|
| SAML 2.0 | XMLベースで認証情報（アサーション）をIdPとSP間でやり取りする標準。エンタープライズSaaSで広く普及。 | 業務向けSaaS、社内Webシステム |
| OpenID Connect（OIDC） | OAuth 2.0の上に作られた認証レイヤー。IDトークンで本人確認を行う。モバイルやAPI連携と相性が良い。 | モバイルアプリ、新しいWebサービス |
| OAuth 2.0 | 本来は「認可（権限の委譲）」の仕組み。認証そのものではない点に注意。OIDCと組み合わせて使われる。 | APIアクセスの権限委譲 |
| エージェント／代理入力型 | IDとパスワードを代行入力するタイプ。古いシステムにも対応できるが、パスワードを保持する点が弱点。 | 標準プロトコル非対応のレガシー |
SAMLとOIDCはどちらが優れているという話ではなく、連携先が対応しているプロトコルに合わせて選ぶのが実務です。米国NISTのデジタルアイデンティティ・ガイドライン（SP 800-63C）でも、SAMLのアサーションとOIDCのIDトークンの双方を有効な方式として扱い、特定のプロトコルを優劣付けてはいません。
SSO導入のメリットは？
SSOの利点は、利便性とセキュリティの両面にあります。
- パスワード管理の負担軽減：利用者が覚えるべき認証情報が減り、使い回しや弱いパスワードを抑制できる。
- 退職・異動時の一括制御：認証基盤側でアカウントを止めれば、連携する全サービスへのアクセスをまとめて遮断できる。
- 多要素認証（MFA）の集約：MFAを認証基盤側に一度入れれば、配下の各サービスに横展開しやすい。
- 監査・可視化：「誰がいつどのサービスにログインしたか」を一元的に把握しやすい。
SSOのリスク・落とし穴は？
最大の注意点は、認証基盤が「単一障害点（Single Point of Failure）」になりやすいことです。便利さの裏返しで、IdPのアカウントが乗っ取られれば、連携する全サービスに一気に侵入されかねません。
- MFAは実質必須：SSOの入口こそ最も守るべき場所。パスワードのみの保護は危険で、多要素認証を前提に設計する。
- IdPの可用性：認証基盤が止まると全サービスにログインできなくなる。障害時の代替手段や緊急用アカウントの扱いを決めておく。
- 実装・設定の不備：SAMLやOIDCは仕様が複雑で、設定ミス（署名検証の不備、リダイレクト先の検証漏れなど）が脆弱性につながった事例が知られている。製品の設定は公式手順に沿って慎重に行う。
- セッションの扱い：一度ログインすれば広く使える分、共有端末での放置やセッション時間の設定にも配慮が必要。
情シスはどう向き合うべきか
SSOは「入れて終わり」ではなく、認証基盤を組織のセキュリティの要として運用し続ける取り組みです。MFAの徹底、棚卸し（誰がどの権限を持つか）、ログの監視、緊急時の代替手順などをセットで設計してください。
ID・パスワードの基本的な考え方や、組織としての対策の全体像は、IPA（情報処理推進機構）の公的な資料が参考になります。まずは下記を出発点にすると、自社の方針に落とし込みやすいでしょう。
- IPA「中小企業の情報セキュリティ対策ガイドライン」：https://www.ipa.go.jp/security/guide/sme/index.html
- IPA「対策のしおり」（エンドユーザ啓発向け）：https://www.ipa.go.jp/security/guide/shiori.html
あわせて、利用者への地道な啓発も欠かせません。SSOで入口が1つになるほど、その1つのパスワードと多要素認証の重要性を現場に伝え続けることが、結局は最も効く対策になります。
まとめ
- SSO（シングルサインオン）とは、一度の認証で複数サービスを使える仕組み。SAMLやOpenID Connectといったフェデレーション方式が主流。
- ID管理の集約と利便性が大きなメリットだが、認証基盤が単一障害点になりやすく、MFAの徹底と設定の正確さが前提となる。
- 「入れて終わり」にせず、棚卸し・ログ監視・緊急時手順をセットで運用し、IPA等の公的指針を出発点に自社方針へ落とし込むとよい。
出典
- NIST SP 800-63C「Digital Identity Guidelines: Federation and Assertions」：https://pages.nist.gov/800-63-3/sp800-63c.html
- OpenID Connect 公式仕様：https://openid.net/developers/how-connect-works/
- IPA「中小企業の情報セキュリティ対策ガイドライン」：https://www.ipa.go.jp/security/guide/sme/index.html
