「社内システムが増えて、システムごとにIDとパスワードを入力するのが面倒になっている」
「退職者のアカウント削除を各システムで行っており、管理が煩雑になっている」
このような課題を解決する方法の一つがSSO（Single Sign-On：シングルサインオン）です。
SSOを導入すると、一度の認証で複数のシステムへログインできる環境を構築できます。
ただし、SSOの導入方法は単純に「ログイン画面を共通化する」だけではありません。
実際には、
- どのサービスを認証基盤にするか
- どのシステムをSSO対象にするか
- SAMLとOpenID Connectのどちらを利用するか
- ユーザー情報をどこで管理するか
- 権限管理をどうするか
- 退職・異動時のアカウント処理をどうするか
- MFA（多要素認証）をどう組み合わせるか
といった設計が必要です。
この記事では、SSOを社内システムへ導入する方法を、システムに詳しくない企業担当者にも分かるように解説します。
SSOとは？一度の認証で複数システムへログインする仕組み
SSOは「Single Sign-On」の略で、一度ユーザー認証を行うことで、複数のシステムやクラウドサービスを利用できる仕組みです。
例えば、社内で次のようなシステムを利用しているとします。
- 勤怠管理システム
- 顧客管理システム
- 案件管理システム
- 経費精算システム
- 社内ポータル
- 独自開発した業務システム
SSOを導入していない場合、それぞれのシステムでログインが必要になることがあります。
利用者は複数のID・パスワードを管理しなければなりません。
一方、SSOを導入すると、
社員
↓
認証基盤でログイン
↓
勤怠管理
↓
顧客管理
↓
案件管理
↓
社内システム
というように、共通の認証情報を利用して複数システムへアクセスできるようになります。
SSO導入の基本的な仕組み
SSOを理解するうえで重要なのが「IdP」と「SP」です。
IdPとは
IdP（Identity Provider）は、ユーザーが本人であることを認証する側です。
例えば、
- Microsoft Entra ID
- Google Workspace
- Okta
などのID管理サービスを認証基盤として利用する方法があります。
利用者はIdPにログインし、IdPが「このユーザーは認証済みです」という情報を各システムへ渡します。
SPとは
SP（Service Provider）は、SSOでログインする対象となるシステムです。
例えば、
- 勤怠管理システム
- CRM
- SaaS
- 社内ポータル
- 独自開発したWebシステム
などです。
大まかな流れは次のようになります。
ユーザー
↓
社内システムへアクセス
↓
IdPへ移動
↓
本人確認
↓
認証結果を社内システムへ返す
↓
ログイン完了
各システムが個別にパスワードを確認するのではなく、認証をIdPへ集約することがSSOの基本的な考え方です。
SSOを導入する方法｜基本の7ステップ
SSO導入では、いきなり設定作業を始めるのではなく、現在利用しているシステムとアカウント管理方法を整理することが重要です。
基本的には次の流れで進めます。
- 現在のシステムとアカウントを洗い出す
- SSO対象システムを決める
- IdPを選定する
- SSO方式・認証プロトコルを決める
- 各システムとIdPを連携する
- 権限・アカウント管理を設計する
- テスト後、段階的に展開する
順番に解説します。
1．現在利用しているシステムとアカウントを洗い出す
最初に行うのは、社内で利用しているシステムの棚卸しです。
例えば次のような一覧を作ります。
| システム | 利用者 | 現在のログイン方法 | SSO対応 |
|---|---|---|---|
| 勤怠管理 | 全社員 | ID・パスワード | 対応 |
| 顧客管理 | 営業部 | ID・パスワード | 対応 |
| 案件管理 | 開発部 | Googleログイン | 対応 |
| 旧基幹システム | 管理部 | 独自認証 | 要確認 |
| 社内Webシステム | 全社員 | 独自認証 | 改修可能 |
ここで重要なのは、有名なクラウドサービスだけを見るのではなく、社内で独自開発したシステムも含めることです。
「どのシステムに誰がログインしているのか」を把握することが、SSO設計のスタート地点になります。
2．SSOを導入するシステムを決める
すべてのシステムを一度にSSO対応させる必要はありません。
まずは、
- 利用人数が多い
- 毎日利用する
- パスワード管理の負担が大きい
- セキュリティ上重要
- SSOへ対応しやすい
といったシステムから進める方法があります。
例えば、
Microsoft 365
↓
勤怠管理
↓
経費精算
↓
社内Webシステム
のように段階的に対象を広げます。
古い業務システムなどではSAMLやOpenID Connectに対応しておらず、改修が必要になる場合もあります。
そのため、SSOの導入範囲を決める前に各システムの仕様確認が必要です。
3．IdP（認証基盤）を選定する
次に、認証の中心となるIdPを決めます。
企業ですでに利用している環境によって候補が変わります。
例えばMicrosoft 365を中心に利用している会社であれば、Microsoft Entra IDを活用できる可能性があります。
Google Workspaceを中心に利用している会社であれば、Googleアカウントを軸にした認証も候補になります。
IdPを選ぶときは、単純なログイン機能だけではなく、
- SAMLへの対応
- OpenID Connectへの対応
- MFAへの対応
- ユーザー管理
- グループ管理
- アクセス制御
- ログ管理
- SaaSとの連携状況
- 料金
などを確認します。
重要なのは、新しい認証サービスを増やすことではなく、現在のID管理をどこへ集約するのが合理的かを考えることです。
4．SAMLかOpenID Connectかを決める
SSOを導入するときによく登場するのが、
- SAML 2.0
- OpenID Connect（OIDC）
です。
どちらもSSOで広く利用される仕組みですが、特徴が異なります。
SAMLとは
SAML（Security Assertion Markup Language）は、IdPとサービス側で認証情報をやり取りするための標準規格です。
企業向けSaaSや既存の業務システムでは、SAMLに対応している製品が多くあります。
例えば、
会社のMicrosoft Entra IDで認証
↓
SAMLで認証情報を送信
↓
業務システムへログイン
といった使い方です。
OpenID Connectとは
OpenID Connect（OIDC）は、OAuth 2.0をベースにした認証の仕組みです。
Webアプリケーションやモバイルアプリなど、比較的新しいシステムで利用されることが多くあります。
例えば自社で新しくWebシステムを開発する場合、
「Microsoftアカウントでログイン」
「Googleアカウントでログイン」
といった認証を実装する際の選択肢になります。
SAMLとOpenID Connectのどちらを使う？
大まかな目安は次の通りです。
| 項目 | SAML | OpenID Connect |
|---|---|---|
| 企業向けSaaSとの連携 | ◎ | ○〜◎ |
| 既存業務システム | ◎ | ○ |
| 新規Webアプリ | ○ | ◎ |
| モバイルアプリ | △ | ◎ |
| データ形式 | XML中心 | JSON中心 |
| 新規システム開発 | ○ | ◎ |
ただし、
「新規開発だから必ずOIDC」
「社内システムだから必ずSAML」
というわけではありません。
対象サービスがどの方式をサポートしているかを確認したうえで決定します。
5．IdPと対象システムを連携する
方式が決まったら、実際にIdPとシステムを接続します。
例えばSAMLでは、
IdP
↓
認証
↓
SAMLによる認証情報
↓
業務システム
という形で連携します。
実際の設定では、
- Entity ID
- Reply URL / ACS URL
- メタデータ
- 証明書
- Name ID
- ユーザー属性
などを設定することがあります。
OpenID Connectの場合は、
- Client ID
- Redirect URI
- Issuer
- Client Secret
- Scope
- ID Token
などの設定が必要になります。
用語を見ると難しく感じますが、本質的には、
「どのIdPを信頼するのか」
「認証後、どのURLへ戻すのか」
「どのユーザー情報を受け取るのか」
を双方で設定していると考えると分かりやすいでしょう。
6．ユーザー管理と権限管理を設計する
SSOで特に注意したいのが、
「認証」と「権限」は別物
という点です。
SSOによって、
「この人は山田さんである」
ことを確認できても、
「山田さんが顧客情報を編集してよいか」
までは自動的に決まるとは限りません。
例えば社内システムに、
- 一般社員
- 営業担当
- 営業管理者
- 経理担当
- システム管理者
という権限がある場合、それぞれ何を閲覧・編集できるかを決める必要があります。
例えば、
一般社員
→ 自分の情報のみ閲覧
営業担当
→ 自分が担当する顧客を閲覧・編集
営業管理者
→ 営業部全体を閲覧
管理者
→ 全データを管理
といった設計です。
SSO導入では、ログイン方法だけではなく権限設計までセットで考えることが重要です。
7．テストしてから段階的に展開する
SSOはログインという重要な機能に関係するため、いきなり全社員へ適用するのは避けた方が安全です。
まずは管理者や一部ユーザーでテストします。
確認する項目としては、
- 正常にログインできるか
- ログアウトできるか
- 権限が正しく反映されるか
- 無効ユーザーがログインできないか
- エラー時にどうなるか
- IdPに障害が発生した場合どうするか
- 管理者がログインできなくなった場合の復旧手段があるか
などがあります。
問題がないことを確認してから対象ユーザーを増やしていきます。
既存の社内システムをSSO対応するには？
クラウドサービスでは、管理画面からSAMLやOpenID Connectを設定するだけでSSOを導入できる場合があります。
一方、独自開発された社内システムでは、アプリケーション側の改修が必要になることがあります。
例えば現在、
ログイン画面
↓
メールアドレス入力
↓
パスワード入力
↓
自社データベースで確認
↓
ログイン
という仕組みだったとします。
SSO導入後は、
社内システム
↓
IdPへリダイレクト
↓
IdPで認証
↓
認証情報を受け取る
↓
社内ユーザーと照合
↓
ログイン
という流れに変更できます。
このとき、
「SSOユーザーと社内データのどの項目を紐づけるか」
も重要です。
メールアドレスだけで識別するのか、IdPから取得した一意のユーザーIDを利用するのかなどを設計します。
SSO導入と同時に考えたいMFA
SSOは利便性を高められる一方、認証基盤のアカウントが重要になります。
一つのアカウントから多数のシステムへアクセスできるためです。
そこでSSOとあわせて検討したいのがMFA（Multi-Factor Authentication：多要素認証）です。
例えば、
パスワード
＋
認証アプリ
など、異なる要素を組み合わせて本人確認を行います。
SSOによってログインを集約するのであれば、
「入口となる認証基盤をどのように保護するか」
まで設計することが重要です。
SSOは単なる利便性向上の仕組みではなく、企業全体のID・アクセス管理を整理する機会として考えるとよいでしょう。
SSOを導入するメリット
SSO導入には、利用者と管理者の双方にメリットがあります。
パスワード管理の負担を減らせる
利用するシステムが増えるほど、従業員が管理する認証情報も増えていきます。
SSOによってログインを集約すれば、システムごとにパスワードを覚える負担を減らせます。
ログイン作業を簡略化できる
毎日利用するシステムが複数ある会社では、
勤怠管理へログイン
↓
CRMへログイン
↓
経費精算へログイン
↓
社内システムへログイン
という作業が発生します。
SSOを導入すると、このログイン作業を簡略化できます。
アカウント管理を集約しやすい
SSOとID管理を適切に組み合わせることで、入社・異動・退職に伴うアカウント管理を整理しやすくなります。
例えば退職時にIdP側のアカウントを無効化し、連携システムへのアクセスを制御する運用を設計できます。
セキュリティポリシーを統一しやすい
各システムが独自に認証していると、
システムA
→ パスワード8文字
システムB
→ MFAあり
システムC
→ パスワード期限あり
といった違いが生まれることがあります。
認証基盤を集約すると、認証ポリシーを統一しやすくなります。
SSO導入のデメリット・注意点
SSOにはメリットがありますが、導入すればすべて解決するわけではありません。
IdPへの依存度が高くなる
認証を一か所へ集約するため、IdPに問題が発生すると複数システムへログインできなくなる可能性があります。
そのため、
- 緊急用管理アカウント
- 障害発生時の対応手順
- 復旧方法
- 管理者権限の扱い
などを事前に設計しておくことが重要です。
すべてのシステムがSSO対応しているとは限らない
新しいクラウドサービスはSSOへ対応していることがありますが、古い社内システムや独自システムでは対応していない場合があります。
その場合、
- システムを改修する
- 認証プロキシなどを利用する
- 一部システムだけ従来認証を残す
などの対応を検討します。
SaaSによってSSOが上位プランの場合がある
クラウドサービスによっては、SAML SSOなどが特定の契約プランでのみ提供されていることがあります。
そのため技術的に対応可能かだけでなく、料金も含めて確認する必要があります。
SSO導入だけでアカウント管理が自動化されるわけではない
よく混同されるのが、
「SSOを導入すれば、ユーザー作成や削除も全部自動になる」
という考え方です。
SSOは主に「認証」を統一する仕組みです。
一方、
- ユーザー作成
- 部署変更
- グループ変更
- アカウント無効化
などのライフサイクル管理は、別途設計が必要です。
利用するサービスによってはSCIMなどの仕組みを利用し、ユーザー情報のプロビジョニングを自動化できる場合があります。
SSO導入前に整理しておきたいチェックリスト
SSO導入を検討している場合は、次の内容を整理すると要件をまとめやすくなります。
【コピペ用】SSO導入ヒアリングシート
- 現在利用しているシステム：
- SSO対象にしたいシステム：
- 各システムの利用人数：
- Microsoft 365利用有無：
- Google Workspace利用有無：
- 現在のユーザー管理方法：
- 現在のログイン方法：
- SAML対応有無：
- OpenID Connect対応有無：
- MFA導入有無：
- 社外からのアクセス有無：
- 管理者と一般社員の権限差：
- 部署ごとの権限差：
- 入社時のアカウント作成方法：
- 異動時の権限変更方法：
- 退職時のアカウント削除方法：
- 外部委託者のアカウント有無：
- 独自開発システムの有無：
- SSO導入希望時期：
すべて決まっていなくても問題ありません。
まず現在の状態を整理することで、
「どこまでSSO化するべきか」
を判断しやすくなります。
SSO導入でよくある失敗
ログイン画面だけを見て設計する
SSO導入で重要なのはログイン画面を減らすことだけではありません。
実際には、
認証
↓
ユーザー管理
↓
権限管理
↓
入社・異動・退職
まで含めて考える必要があります。
いきなり全システムをSSO化する
対象システムが多い場合、一度に移行するとトラブル時の影響範囲も大きくなります。
まず主要なシステムから小さく始め、段階的に対象を広げる方が進めやすいでしょう。
権限管理を後回しにする
ログインできるようになっても、必要以上のデータを閲覧できる状態では問題があります。
認証と権限は分けて設計する必要があります。
退職者対応を設計していない
特に重要なのが退職時の処理です。
SSOを導入するのであれば、
退職
↓
IdPアカウント無効化
↓
各システムへのアクセス停止
↓
必要に応じて個別アカウントも削除
という流れを整理しておきます。
SSOに関するよくある質問
SSOは小規模企業でも導入できますか？
導入できます。
ただし、利用システムが2〜3個しかなく、アカウント管理にも困っていない場合は、SSOを導入する効果が小さいこともあります。
システム数、利用人数、アカウント管理負担をもとに判断するとよいでしょう。
既存の社内システムでもSSOにできますか？
可能な場合があります。
対象システムがSAMLやOpenID Connectに対応している場合は連携しやすく、独自認証の場合はシステム改修が必要になることがあります。
Microsoft 365を使っていればSSOを導入できますか？
Microsoft Entra IDをIdPとして、対応するアプリケーションとSSO連携できる場合があります。
ただし、対象システム側の対応方式や契約プランも確認が必要です。
SAMLとOpenID Connectはどちらがよいですか？
既存の企業向けSaaSではSAML、新しく開発するWebアプリケーションではOpenID Connectが候補になることが多いですが、最終的には対象システムとIdPが対応する方式から選びます。
SSOを導入すればパスワードは不要になりますか？
必ずしもそうではありません。
SSOは複数システムへの認証を集約する仕組みであり、IdPへのログイン方法は別途決めます。
パスワード、MFA、パスキーなど、組織のセキュリティ要件に合わせた認証方式を検討します。
SSOとMFAはどちらを導入すべきですか？
役割が異なるため、どちらか一方という考え方ではありません。
SSOはログインを統合する仕組み、MFAは本人確認を強化する仕組みです。
SSOの認証基盤にMFAを組み合わせる方法が考えられます。
hiro-dev-labではSSO導入前の要件整理から相談できます
SSO導入では、SAMLやOpenID Connectの設定だけに注目しがちです。
しかし実際には、
- 現在利用しているシステム
- ユーザー管理
- 認証方法
- 権限
- 入社・異動・退職
- 外部ユーザー
- 既存社内システム
まで整理したうえで設計する必要があります。
特に独自開発された社内システムがある場合、
「現在のログイン機能をどのようにSSOへ変更するか」
というアプリケーション側の設計・改修も必要になります。
hiro-dev-labでは、SSOそのものを目的にするのではなく、現在の業務やシステム構成を整理したうえで、
- 現状システムの整理
- SSO対象範囲の整理
- 要求整理
- 要件定義
- ユーザー・権限設計
- 認証方式の検討
- 既存Webシステムの改修方針整理
- Webシステム開発
といった観点から相談できます。
「SSOを導入したいが、何から調べればよいか分からない」
「Microsoft Entra IDやGoogle Workspaceと社内システムを連携できるのか知りたい」
「既存のID・パスワード認証をSSOへ変更したい」
という段階であれば、まず現在利用しているシステムとログイン方法を一覧にするところから始めるとよいでしょう。
まとめ
SSOの導入方法は、大きく次の流れになります。
- 社内システムを洗い出す
- SSO対象を決める
- IdPを選定する
- SAML・OpenID Connectなどの方式を決める
- IdPと各システムを連携する
- ユーザー・権限管理を設計する
- テストして段階的に展開する
特に重要なのは、SSOを「ログイン画面を一つにする仕組み」だけで考えないことです。
認証を統一するのであれば、
- 誰がアカウントを管理するのか
- 誰がどのシステムを利用できるのか
- 異動時に権限をどう変更するのか
- 退職時にどうアクセスを停止するのか
- 認証基盤そのものをどう守るのか
まで考える必要があります。
SSO、MFA、ユーザー管理、権限管理をまとめて設計することで、利用者にとって使いやすく、管理者にとっても運用しやすい認証基盤を構築できます。