SSOとは

この記事は約 2 分で読めます

シングルサインオン (SSO: Single Sign-On) とは、一度の認証で複数のサービスやアプリケーションにアクセスできる仕組みです。ユーザーはサービスごとに個別のパスワードを入力する必要がなくなり、利便性が大幅に向上します。企業の社内システムやクラウドサービスで広く導入されています。一人が業務で使うクラウドサービスが増えるほど、サービスごとのパスワードを個別に管理しきれなくなるため、認証を 1 か所へ集約する SSO の必要性が高くなります。

SSO と OAuth の違い

SSO と OAuth は関連する技術ですが、解決する課題が異なります。 SSO は「一度の認証で複数サービスにログインする」という認証の利便性を提供します。 OAuth は「パスワードを渡さずにアプリに権限を委譲する」という認可の安全性を提供します。実装面では、 SSO は SAML 2.0 や OpenID Connect (OIDC) といったプロトコルで実現されます。 OIDC は OAuth 2.0 の上に認証レイヤーを追加したもので、 OAuth の認可機能と SSO の認証機能を統合しています。企業向けの SSO では SAML が、コンシューマー向けのソーシャルログインでは OIDC が主流です。

SSO の仕組み

SSO では、中央の認証サーバー (IdP: Identity Provider) がユーザーの認証を一元管理します。ユーザーが IdP で認証を完了すると、認証トークンが発行され、連携する各サービスはこのトークンを検証してアクセスを許可します。代表的な IdP には Okta 、 Microsoft Entra ID (旧 Azure AD) 、 Google Workspace などがあります。

現場での使用例

例えば、社内システムとクラウドサービスがそれぞれ別のパスワードで運用されている組織を SSO 基盤へ統合する場合、最初に変化が見えるのは日々のログイン操作よりも、ヘルプデスクのパスワードリセット対応です。入社時のアカウント作成と退職時の停止も IdP 側の操作にまとまるため、退職者のアカウントが個別サービスに取り残される事故が起きにくくなります。一方で、 SSO に対応していない業務ツールが残っていると効果は部分的にとどまります。統合の前にどのサービスを対象にできるか棚卸しをしたかどうかで、結果は大きく変わります。

SSO フロー

実務でのリスクと対策

SSO は便利ですが、「単一障害点」になるリスクがあります。 SSO の認証情報が漏洩すると、連携する全サービスに影響が及びます。このリスクを軽減するため、 SSO アカウントには特に強力なランダムパスワードを設定し、多要素認証を必ず有効にしましょう。実務でよくある落とし穴は、 SSO を導入したことで「パスワード管理は不要」と考えてしまうことです。 SSO に対応していないサービスは依然として存在し、それらには個別の強力なパスワードが必要です。また、 SSO プロバイダーの障害時に全サービスにログインできなくなるリスクも考慮し、緊急時のバイパス手段を事前に確保しておくことが重要です。