先に要点
SSO は便利そうだけど、入れた方がいいのか、どこが大変なのかが分かりにくい という人は多いです。
実際、現場では「ログイン回数が減る」よりも「認証を中央に寄せられる」「退職者や異動の反映をそろえやすい」といった運用面の価値が大きく、同時に 入口に障害や設定ミスの影響が集まりやすい という怖さもあります。
このページでは、2026年4月4日時点で Microsoft Learn の SSO 関連資料、OpenID Foundation の OpenID Connect 解説、IETF の OAuth 2.0 仕様、OASIS の SAML 技術資料、CISA の Secure by Design と Cybersecurity Performance Goals の公開情報を確認しながら整理しています。
社内システム全体の対策から見たい場合は、社内の業務システムを構築する際のセキュリティ対策は？どこまでやるべきかを整理 もあわせて読むとつながりやすいです。
生成AI の社内利用まで含めて、入力ルールや承認フローをどう設計するか見たい場合は、生成AIを社内で使うときのセキュリティ対策は？入力ルールと運用設計を解説 も合わせて読むとつながりやすいです。
SSOとは何か
ざっくり言うと、SSO は 一つの認証基盤で複数のサービスへ入れるようにする仕組み です。
ユーザーから見ると「毎回ログインしなくてよい」が分かりやすい利点ですが、運用側から見ると「アカウント管理を散らさない」「強い認証を入口に集約しやすい」が本当の価値です。
たとえば、社内でグループウェア、チャット、経費精算、ワークフロー、社内ツールが全部バラバラのID管理だと、こういう事故が起きやすくなります。
- 退職者のアカウント停止漏れが出る
- 権限変更が片方だけ反映される
- MFA の有無がシステムごとにばらつく
- 監査ログを追うときに誰が誰か分かりにくい
SSO を入れると、少なくとも 認証の入口 を寄せやすくなります。
ただし、SSO 自体が権限管理や端末管理を全部やってくれるわけではありません。そこはよくある誤解です。
仕組みをざっくり言うと
SSO の説明では、まず IdP とアプリ側の役割を分けて考えると分かりやすいです。
- IdP: 誰なのかを確認する側
- アプリ側: その確認結果を受けて利用させる側
- 連携方式: SAML や OpenID Connect など
実務では、ユーザーがアプリを開く -> IdP で認証する -> 認証結果をアプリへ渡す -> アプリが利用を許可する という流れで動きます。
Web 系のSaaSでは OpenID Connect や SAML がよく出てきます。
| 方式 | 役割 | よくある用途 |
|---|---|---|
| SAML | 認証連携（XMLベース） | 企業向けSaaS、社内システム連携 |
| OpenID Connect | 認証（OAuth 2.0の上に構築） | Web/モバイルアプリのログイン |
| OAuth 2.0 | 認可（リソースへのアクセス許可） | API連携、外部サービス連携 |
| SCIM | アカウント自動管理 | 入退社・異動時のユーザー同期 |
ここで混同しやすいのが OAuth 2.0 です。
OAuth 2.0 は本来 認可 の仕組みで、OpenID Connect はその上に認証の仕組みを載せたものです。
現場では「OIDC でログイン」「OAuth でAPI連携」というように分けて考えると整理しやすいです。
次の図で、ユーザーがアプリを開いてから SSO でログインが完了するまでの流れをステップごとに確認できます。
SSOが便利な理由
SSO は確かに便利です。
ただ、便利さは ユーザーが楽 だけでなく、運用の揃えやすさにもあります。
利用者側のメリット
- 毎回別々のIDとパスワードを覚えなくてよい
- 入口で一度認証すれば、複数サービスへ入りやすい
- パスワード使い回しの誘惑が減る
管理側のメリット
- 認証方式を中央に寄せやすい
- MFA を入口で必須にしやすい
- 異動や退職時のアカウント整理をそろえやすい
- ログを見たときに主体を追いやすい
CISA の Secure by Design でも、MFA、ログ、SSO を追加料金なしで使える状態が望ましいと示されています。
これは「SSO があると便利」という話より、「認証や証跡の基本機能を標準で使えるべき」という考え方です。
便利さの裏で運用が重くなるところ
SSO は入れれば終わり、ではありません。
むしろここを軽く見ると、導入後にじわじわ苦しくなります。
1. アカウントライフサイクルを揃える必要がある
IdP に寄せたのに、アプリ側で個別ユーザー作成や個別権限付与が残っていると、運用はきれいになりません。
実務では、入社、異動、休職、退職のタイミングで誰がどう更新されるかを決めておく必要があります。
ここで役に立つのが SCIM のようなプロビジョニング連携です。
ただ、SCIM があるから自動で全部きれいになるわけでもありません。属性の対応表や例外時の運用を詰めないと、結局は手作業が残ります。
2. 例外アプリが必ず出る
現場では、全部のシステムが同じように SSO 対応しているとは限りません。
この 例外をどう扱うか を決めないまま入れると、かえって認証方式が増えて混乱します。
最初から「今回は SSO 対応SaaSを優先する」「古いシステムは後回しにする」と線を引いた方が進めやすいです。
3. 入口障害の影響が大きい
認証を中央に寄せるということは、IdP 側の障害や設定ミスの影響も集まるということです。
たとえば、条件付きアクセス、MFA、フェデレーション設定、証明書更新でミスがあると、複数システムへ一気に影響します。
なので実務では、次のような備えがほぼ必須です。
- 緊急用の管理者アカウントを別で持つ
- 証明書期限や連携設定変更の確認手順を持つ
- 障害時にどこまで入れなくなるかを整理する
- 重要システムのバックドアではなく、正式な緊急運用手順を決める
セキュリティの観点で見ると何が大事か
SSO はセキュリティを良くしやすい仕組みですが、雑に入れると 入口が強いだけで中が甘い 状態になります。
MFAを前提にする
SSO の入口がパスワード単独だと、認証をまとめた意味がかなり薄れます。
CISA の Cybersecurity Performance Goals でも、特にリモートアクセスや重要アカウントでは MFA が重要とされています。
最近は、パスワード前提の運用そのものを見直す選択肢として、Passkeysとは？パスワード・2FAとの違いを初心者向けにわかりやすく解説 も比較対象に上がることが増えています。
少なくとも、次は優先したいです。
- 管理者
- 承認権限を持つ人
- 外部からアクセスする人
- 機密データを扱う人
権限は別で絞る
SSO を入れても、全員が同じ範囲へ入れる状態では安全になりません。
権限は RBAC やグループベースで分けて、到達先を役割ごとに整理する必要があります。
ここをサボると、ログインは安全になったけど、入った後の見えすぎが残る という状態になります。
セッションとログを軽く見ない
実務では、ログインそのものよりも ログインした後に何ができたか の方が重要になる場面が多いです。
なので、SSO 導入時は次も一緒に見ます。
- セッション有効時間
- 再認証が必要な操作
- 管理者操作のログ
- 失敗ログインや異常な地域・端末からのアクセス
退職者・外部委託・休眠アカウントの整理
SSO はアカウント停止を寄せやすくしますが、整理しなければ意味がありません。
特に外部委託や短期アカウントは残りやすいので、棚卸しの周期を決めておいた方が安全です。
実際に導入するときの進め方
SSO は、いきなり全社一斉で広げるより、順番を決めた方がうまくいきます。
- まず対象システムを棚卸しする
どのSaaSがあるか、認証方式は何か、誰が管理しているかを出します。 - IdP の入口ポリシーを決める
MFA、許可端末、管理者の扱い、緊急アカウントの方針を決めます。 - 優先度の高いシステムからつなぐ
毎日使うSaaS、権限の強いシステム、退職者停止漏れが怖いものを先に寄せます。 - 権限とプロビジョニングを整える
グループ設計、属性設計、SCIM の有無、例外運用を詰めます。 - ログと障害時手順まで決める
入れないときの連絡先、切り分け、緊急用アカウント、証明書更新手順まで残します。
とりあえず SSO に寄せる だけで始めると、運用担当だけがつらくなることが多いです。
逆に、対象システム、権限、例外、障害時手順まで最低限決めてから進めると、後から崩れにくくなります。
よくある誤解
SSO を入れれば自動で安全になるわけではありません。入口の認証をまとめやすくなるだけで、権限の広さ、退職者対応、端末の安全性、ログの見方までは別で整える必要があります。
よくある誤解はこのあたりです。
- SSO を入れればパスワード問題が全部なくなる
- SSO と MFA は同じもの
- SSO を入れれば権限設計は後回しでよい
- 一度つないだら運用設計は要らない
実際は、認証を寄せる仕組み と 安全に運用する仕組み は分けて考える方が実務ではうまくいきます。
まとめ
SSO は、単にログインを楽にする仕組みではなく、認証を中央に寄せて運用しやすくする仕組みです。
一方で、入口に影響が集まりやすいので、MFA、権限設計、ログ、退職者対応、例外システムの扱いまで一緒に考えないと、便利さだけが先に立って運用が苦しくなります。
もし最初の一歩で迷うなら、毎日使うSaaS と 権限が強いシステム から寄せるのがおすすめです。
そのうえで、SSO、MFA、RBAC、SCIM をセットで見ると、かなり判断しやすくなります。
参考情報
- Microsoft Learn: What is single sign-on in Microsoft Entra ID?
- Microsoft Learn: Plan a single sign-on deployment
- Microsoft Learn: SAML authentication with Microsoft Entra ID
- OpenID Foundation: How OpenID Connect Works
- IETF: RFC 6749 The OAuth 2.0 Authorization Framework
- OASIS: Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0
- CISA: Secure by Design
- CISA: Cybersecurity Performance Goals (CPGs)