SSO連携とは？
導入メリットと具体的なグループウェアへの設定手順を解説
SSO（シングルサインオン）はユーザーが1回のログイン認証で複数のシステムやアプリケーションにアクセスできるようになる技術です。SSOにより、ユーザーのパスワード管理負担が軽減され、認証・認可の仕組みによるセキュリティ強化が可能です。
SSOを各システムで利用するためには、SSOを実現する認証基盤と連携する必要があります。
本記事では、SSO連携の方法を2つのサービスを例に挙げて解説します。
目次
SSO連携とは？
SSO（シングルサインオン）を利用することで、ユーザーは1回のログイン認証で複数のシステムやアプリケーションにアクセスできます。各システムへSSOでログインするためには、SSOを実現する認証基盤との連携が必要です。
まずはSSOの基本概念と、SSO連携の主な用途について解説します。
SSO（シングルサインオン）の基本概念
SSOはユーザーが1回のログイン認証で複数のシステムやアプリケーションにアクセスできるようになる技術です。
例として、企業が社内システムにSSOを導入している場合を考えてみましょう。従業員は認証基盤（例としてMicrosoft Entra ID）にログインするだけで、Microsoft 365はもちろん、Salesforceなどの他のサービスにもログインが可能です。
SSOを導入すれば、ユーザーはサービスごとにID・パスワードを管理する必要がなくなります。認証基盤のログイン情報だけを管理すればよいためです。また認証基盤に生体認証など多要素認証を導入すると、不正アクセスのリスクをより低減できます。
SSOを実現する基本的な仕組みとして、主に以下の3つの方式が広く採用されています。
- セッションベース方式
- トークンベース方式
- フェデレーション方式
SSO連携の主な用途
SSO連携が用いられるケースとして、社内にある複数のシステムへのログイン統合が挙げられます。
一般的に、従業員は複数の社内システムを利用します。例えば、グループウェア、ERP、CRM、開発環境などへのログインです。SSO連携では、これらシステムへのログインを効率化し、業務効率化を実現します。
また、認証・認可の設定を広範囲に適用したいケースもあるでしょう。
SSO連携をすると、連携先のサービスにも認証・認可ポリシーを適用できるため、アクセス制限を容易に行えます。例えば、部署ごとにアクセス可能なサービスを限定したり、派遣社員がサービスにログインできる時間帯を制限したりすることも可能です。
クラウドの安全は誰が守る？ 責任共有モデルとセキュリティ対策
クラウド提供者と利用者の責任範囲を明確にし、情報漏えいを防ぐためのDLP（Data Loss Prevention）を解説します。
Microsoft 365導入前に知っておきたいセキュリティ対策
Office 2019及び2016からの移行、セキュリティ対策、HENNGE One連携…etc 押さえるべきポイント解説！
SSO連携のメリット
SSO連携のメリットとして以下のようなメリットがあります。
- ユーザー体験向上
- セキュリティ強化
- 管理コスト削減
- ゼロトラストセキュリティ実現への貢献
ユーザー体験向上
SSO連携により、ユーザーは複数のシステムやサービスへアクセスする際に、何度もログイン作業を行う必要がなくなります。毎回異なるアカウント情報を入力する手間が省け、利便性が大幅に向上します。
業務において複数のシステムやサービスを利用することは一般的です。アクセスするたびにログインを求められることは業務を中断させるストレス要因となりますが、SSO連携によってこのストレスから解放されます。また、モバイルデバイスやリモートワーク環境においてもSSOは有効です。
SSO連携によるスムーズな認証プロセスは、業務の生産性向上に貢献します。
セキュリティ強化
SSOはセキュリティ強化に貢献します。
従来のパスワード認証では、ユーザーが複数のパスワードを管理する必要があり、パスワードの使い回しや漏えいリスクが高まります。ユーザーが管理を面倒に感じて同じパスワードを使い回すと、1つのパスワードが漏えいした場合の被害が拡大する懸念があります。
SSOは、これらのリスクに対する有効な対策となります。SSO連携により、ユーザーは1つの強力なパスワードを管理するだけで済むようになり、安全性が向上します。SSOと多要素認証（MFA）を組み合わせることで、万が一パスワードが漏えいした場合でも、不正アクセスを効果的に防ぐことができます。
また、SSOは認可との親和性も高く、ユーザーやグループ単位でのアクセス制御が容易である点も特徴です。アクセス権限を必要最小限に留めることで、情報漏えいのリスクも最小限に抑えることができます。
管理コスト削減
SSO連携は、パスワードやアカウントの管理に関わるコスト削減にもつながります。
ユーザーにとっては、パスワード管理の手間が軽減されます。複数のパスワードを記憶・管理する必要がなくなり、1つの強力なパスワードで運用できるためです。
また、IT管理者の管理負担軽減にも貢献します。
例えば、ユーザーが個別のパスワードを忘れた際のパスワードリセット対応件数が大幅に減少するでしょう。また、従業員の異動や退職時には、複数のシステムのアカウントを一元的に管理できるため、迅速なアクセス権限の変更やアカウント削除が可能になります。
SSO連携によって、こうした目に見えにくい管理コストを削減できる点もメリットです。
ゼロトラストの実現に貢献
SSO連携は、ゼロトラストセキュリティモデルの実現にも貢献します。
ゼロトラストは、「すべてのアクセスを信頼しない（Never Trust, Always Verify）」という原則に基づいており、従業員が社内システムにアクセスする場合も例外ではありません。内部不正による情報漏えいのリスクも考慮します。
SSOを用いてユーザーのアクセス権限を適切に管理し、必要以上の権限を与えないことで、情報漏えいのリスクを最小限に抑えることができます。各サービスへのログインもSSOによる認証を経ているため、「誰が、いつ、どの情報にアクセスしたか」といったログを正確に記録・追跡しやすくなり、責任の所在を明確にすることができます。これにより、なりすまし防止や、万が一情報漏えいが発生した場合の原因究明が容易になります。
ゼロトラストの概念とSSO連携は、親和性が高いと言えるでしょう。
SSO連携の方式と認証プロトコル
SSO連携には複数の実装方式や認証プロトコルが存在します。ここでは、それぞれについて簡単に解説します。
より詳しく知りたい方は、以下の関連記事も併せてご覧ください。
関連記事：
シングルサインオン（SSO）とは？仕組みや認証方式をわかりやすく解説
SSOの実装方式
主なSSOの実装方式には、以下の3つがあります。
- セッションベース方式
- ユーザーが初回認証後、セッションが確立される
- 以降のアクセスでは再認証なしでログインできる
- トークンベース方式（OAuth 2.0 / OpenID Connectなど）
- 認証後にアクセストークンが発行され、ユーザー側（クライアント）で保持する
- ユーザーが各サービスへアクセスする際に、このトークンを提示することで認証が行われる
- フェデレーション方式（SAML 2.0など）
- 1回の認証後、認証基盤（IdP）が認証情報を管理し、ユーザー側では認証情報を直接保持しない
- 信頼関係にある異なるドメイン（サービスプロバイダー、SP）間で認証情報を安全に連携し、ユーザーのログインを許可する
主な認証プロトコル
SSO連携で主に使用される認証プロトコルには、以下のようなものがあります。
- SAML 2.0（Security Assertion Markup Language）
- 主に企業向けWebサービスのSSOで利用されるフェデレーション認証プロトコル
- IdP（Identity Provider）とSP（Service Provider）間で認証情報（アサーション）を送受信する
- OpenID Connect（OIDC）
- OAuth 2.0を拡張した「認証」のためのプロトコル
- OAuth 2.0
- モバイルアプリ、Webアプリケーション、APIアクセスなどで広く利用される「認可」のためのフレームワーク
- JSONベースのトークン（アクセストークンなど）を使用する
- 主な目的は認証（Authentication）ではなく、認可（Authorization、アクセス権限の委譲）である
- OAuth 2.0
- Webサービス間の認証統合に適用
- IDトークン（JWT）にユーザー情報（名前、メールアドレスなど）が含まれる
- OAuth 2.0を拡張した「認証」のためのプロトコル
SSO連携の設定方法（具体的な設定方法）
ここでは以下の2つのサービスを例に、SSO連携の具体的な設定手順を解説します。
- Google Workspace
- Microsoft 365
Google WorkspaceのSSO連携の設定方法
Google WorkspaceはSAMLまたはOIDCによるSSO連携が可能です。ここでは、OIDCを利用した設定方法を解説します。
前提条件
事前に以下の設定が必要です。
- IdP（Identity Provider）認証サーバーの完全なURL
- （IdP側で設定する）パスワード変更用URL
- （IdP側での）OAuthクライアントの作成
また、Google Workspace側でもカスタムOIDCプロファイルを作成する必要があります。
- 管理者アカウントでGoogle管理コンソールにログイン
- メニューアイコン > [セキュリティ] > [認証] > [サードパーティの IdP による SSO] の順にクリックします。
- [サードパーティの SSO プロファイル] で [OIDC プロファイルを追加] をクリックします。
- OIDCプロファイルの名前と、IdPから取得した詳細情報（発行者URL、クライアントID、クライアントシークレットなど）を入力します。
- [保存] をクリックします。
保存後に表示されるGoogleのリダイレクトURIをコピーし、IdP側のOAuthクライアント設定に追加してください。
OIDC用SSOプロファイルの割り当て準備
- 管理者アカウントでGoogle管理コンソールにログイン
- メニューアイコン「セキュリティ」「認証」「サードパーティのIdPによる SSO」の順に遷移
- 「サードパーティのSSOプロファイル」「SAMLプロファイルを追加」をクリック
- プロファイル名を入力
- 必要情報の入力と、証明書のアップロード
- 「保存」をクリック
SSO設定の割り当てと有効化
作成したOIDCプロファイルを組織部門またはグループに割り当てることで、SSOを有効化します。以下の手順で行います。
- [SSO プロファイルの割り当てを管理] をクリックします。
- 初めて割り当てる場合は [使ってみる] をクリックします。
- SSOを有効にする組織部門またはグループを選択します。
- 割り当てる SSO プロファイルとして、先ほど作成したカスタムOIDCプロファイルを選択し、[保存] をクリックします。
- 「保存」をクリック
設定が完了したら、対象の組織部門またはグループに所属するユーザーが、IdP経由でGoogle WorkspaceにSSOできるかテストしましょう。
Microsoft 365のSSO連携の設定方法
Microsoft 365でもSSO連携が可能です。以下の関連記事でもMicrosoft 365のSSOについて解説していますので、併せてご覧ください。
関連記事：
Microsoft 365でシングルサインオン（SSO）を実現するには？3つの実現方法を解説
ここでは、Microsoft Entra ID（旧Azure Active Directory）を利用したパススルー認証（PTA）によるシームレスSSOの設定方法を解説します。
Microsoft Entra ID 環境の前提条件
事前に以下が必要です。
- Microsoft Entra テナントのグローバル管理者アカウント、またはハイブリッドID管理者アカウント
- アカウントの準備
■Microsoft Entra 管理センターにユーザー管理者以上の権限でサインインします。
■[ID] > [ユーザー] > [すべてのユーザー] > [新しいユーザー] > [新しいユーザーの作成] の順にクリックします。
■必要なユーザー情報を入力します。
■[ロール] で [グローバル管理者] または [ハイブリッド ID 管理者] を割り当てます。
■[確認と作成] > [作成] をクリックします。
- アカウントの準備
- Microsoft Entra テナントに検証済みのカスタム ドメイン名が1つ以上追加されていること。
- カスタムドメインの追加
■Microsoft Entra 管理センターにドメイン名管理者以上の権限でサインインします。
■[ID] > [設定] > [ドメイン名] > [カスタム ドメインの追加] の順にクリックします。
■カスタム ドメイン名を入力し、[ドメインの追加] をクリックして検証プロセスを完了します。
- カスタムドメインの追加
オンプレミス環境の前提条件
オンプレミス環境には、Microsoft Entra Connect をインストールするためのサーバーが必要です。サーバーは以下の要件を満たす必要があります。
- OS: Windows Server 2016 以降
- TLS 1.2 が有効であること
また、ファイアウォールやプロキシサーバーがある場合は、Microsoft Entra Connect が正常に動作するために、特定のポートと URL (フィルター) への通信を許可する必要があります。
- 許可が必要なポート:
- TCP 80
- TCP 443
- TCP 8080 (※Connect Health Agent用、要確認)
- 許可が必要な URL (フィルター):
- *.msappproxy.net, *.servicebus.windows.net (※PTA Agent用)
- login.microsoftonline.com (※古いエンドポイントのため統一)
- login.microsoftonline.com
Microsoft Entra Connect のインストールと構成
以下の手順で Microsoft Entra Connect をインストールし、パススルー認証とシームレスSSOを有効にします。
- 前提条件を満たすオンプレミスサーバーに、Microsoft Entra Connect をダウンロードします。
- ダウンロードしたファイルを実行し、インストールウィザードを開始します。
- [ようこそ] 画面でライセンス条項とプライバシーに関する声明に同意し、[続行] をクリックします。[簡単設定] 画面で [カスタマイズ] を選択します。
- [必須コンポーネントのインストール] 画面で、必要に応じてインストール場所を変更し、[インストール] をクリックします。
- [ユーザー サインイン] 画面で [パススルー認証] を選択し、[シングル サインオンを有効にする] チェックボックスをオンにします。[次へ] をクリックします。
- [Microsoft Entra ID への接続] 画面で、Microsoft Entra ID のグローバル管理者アカウントの資格情報を入力し、[次へ] をクリックします。
- [ディレクトリの接続]、[ドメインと OU のフィルタリング]、[一意なユーザーの識別]、[ユーザーとデバイスのフィルタリング]、[オプション機能] の各画面で、環境に合わせて設定を行い、[次へ] をクリックします。
- [シングル サインオンを有効にする] 画面で、オンプレミス Active Directory のドメイン管理者アカウントの資格情報を入力し、[次へ] をクリックします。[構成の準備完了] 画面で内容を確認し、[インストール] をクリックします。インストール完了後、[終了] をクリックします。
設定のテスト
以下の手順で、パススルー認証が正しく有効化されたかを確認します。
- Microsoft Entra ID の管理者アカウントで Microsoft Entra 管理センターにサインインします。
- [Microsoft Entra ID] > [Microsoft Entra Connect Health] を選択します。
- [同期サービス] > [サーバー名] をクリックし、[認証エージェント] タブでエージェントの状態が [アクティブ] であることを確認します。また、[Microsoft Entra ID] > [Microsoft Entra Connect] > [Connect 同期] > [パススルー認証] で状態が [有効] になっていることを確認します。
SSO連携のよくある課題とトラブルシューティング
SSO連携で発生しやすい課題には、以下のようなものがあります。
- ログインエラー（HTTP 401 / 403 エラーなど）
- 属性情報の不一致
- SAML レスポンスの検証エラー
- OAuth 2.0 アクセストークンの無効化
それぞれの課題に対するトラブルシューティング方法と併せて解説します。
ログインできない（401 / 403エラー）
ユーザーがSSOでログインしようとした際に、認証エラーが発生することがあります。代表的なエラーコードとして、以下の2つが挙げられます。
- 401 Unauthorized: 認証情報が無効、または間違っている場合に返されます。
- 403 Forbidden: 認証は成功したものの、要求されたリソースへのアクセス権限がない場合に返されます。
まず、ユーザーが入力したユーザーIDやパスワードが正しいか、多要素認証（MFA）の設定（使用デバイスなど）に誤りがないかなど、ユーザー側の操作を確認します。ユーザー側に問題がない場合は、システム側の設定を確認します。
システム側でエラーが発生する主な原因としては、IdP と SP の設定不備（特にアクセス許可設定）、証明書の有効期限切れなどが考えられます。トラブルシューティング時の主な確認ポイントは以下の通りです。
- IdP と SP におけるアクセス制御ポリシーの設定内容
- ユーザーアカウントが、アクセスに必要なグループやロールに正しく割り当てられているか
- 発行されるトークン（SAMLアサーションやOAuthトークン）の有効期限やスコープ（権限範囲）の設定
属性情報の不一致
属性情報の不一致により、SSOが失敗することがあります。
属性情報とは、ユーザーアカウントに関連付けられた情報（例: メールアドレス、氏名、部署、役職など）を指します。SSOプロセスでは、認証情報（ユーザーIDやパスワードなど）に加えて、これらの属性情報が IdP から SP へ連携され、ユーザー識別やアクセス制御に利用されます。
属性情報の不一致が原因で SSO が失敗する場合、IdP と SP 間でユーザー情報を連携するための設定（属性マッピング）に誤りがあるか、連携されるべき属性値自体が IdP または SP 側で異なっている可能性があります。
トラブルシューティング時の主な確認ポイントは以下の通りです。
- IdP と SP 間で設定されている属性マッピング（どの属性をどの名前で連携するか）が正しいか
- IdP から SP が要求する属性情報が、SAML アサーションや ID トークンに含まれて送信されているか
- SP 側のユーザーデータベースに、連携される属性情報を受け入れられる形でユーザー情報（例: ユーザー名やメールアドレス）が登録されているか
SAMLレスポンスの検証エラー
IdP から SP へ送信される SAML レスポンスの検証に失敗すると、SSO は完了しません。
SAMLレスポンス自体の問題（署名検証失敗、有効期限切れ、形式不正など）が原因です。レスポンス検証エラーの主な原因としては、以下のようなものが考えられます。
- SAML レスポンスの署名に使用された証明書が SP 側で信頼されていない、または有効期限が切れている
- IdP と SP のシステム時刻に大きなズレがあり、レスポンスの有効期間外と判断される
- レスポンスに含まれる属性情報の形式や名前が SP の期待するものと異なる
トラブルシューティング時の主な確認ポイントは以下の通りです。
- IdP と SP 間で交換・設定されている署名証明書が正しいか、有効期限内か
- IdP と SP のシステム時刻が同期されているか（NTPサーバーなどの利用を確認）
- IdP と SP の属性マッピング設定が正しいか
OAuth 2.0のアクセストークンが無効
OAuth 2.0 / OIDC を利用した SSO では、アクセストークンや ID トークンが無効な場合に認証が失敗します。
OAuth 2.0 のアクセストークンは、ユーザーが IdP (認可サーバー) で認証・認可された後、クライアントアプリケーション (SP に相当) が保護されたリソース (API など) へアクセスするために取得する資格情報です。このトークンが無効な場合、リソースへのアクセスは拒否されます。トークンが無効になる主な原因としては、以下のようなものが考えられます。
- アクセストークンの有効期限切れ
- 要求されたスコープ（権限範囲）が、クライアントアプリケーションに許可されていない、またはトークンに含まれていない
- トークン（特に ID トークン）の署名検証に失敗した（IdP の署名キーが変更された、など）
トラブルシューティング時の主な確認ポイントは以下の通りです。
- トークンの有効期限を確認し、期限切れの場合はトークンを再取得するプロセス（リフレッシュトークン利用など）が正しく動作しているか
- クライアントアプリケーションが要求しているスコープが、IdP 側で登録・許可されているスコープと一致しているか
- クライアントアプリケーション (SP) 側で、IdP の公開鍵 (署名検証用) が最新のものに更新されているか
まとめ
SSOを導入することで、ユーザーの利便性向上とセキュリティ強化を両立できます。一般的に、セキュリティ対策強化はユーザーの利便性とトレードオフの関係になりがちですが、SSO はその両立を実現できる効果的なソリューションです。
「HENNGE One Identity Edition」は、専門的な知識が必要とされる、SSO環境の構築や設定を専門のエンジニアが手厚くサポートします。
HENNGE Oneは、ゼロトラストに基づくアクセス管理機能を備えた、国内シェアNo.1（※）のクラウドセキュリティサービスです。HENNGE Oneを導入することで、情報資産の安全性を高め、より効率的な運用を目指すことが可能です。
ぜひご検討・お気軽にご相談ください。
※ ITR「ITR Market View：アイデンティティ・アクセス管理／個人認証型セキュリティ市場2025」IDaaS市場：ベンダー別売上金額シェアにて2021年度、2022年度、2023年度、2024年度予測の4年連続で1位を獲得
