outputシングルサインオン（SSO）とは？仕組み・種類・セキュリティリスクと対策をわかりやすく解説

ひとつのIDとパスワードで複数のサービスに入れる「シングルサインオン（SSO）」。Microsoft 365やGoogle Workspaceを使っている企業なら、すでに日常的に活用しているはずです。

便利な反面、IdP（認証を担う仕組み）が突破されると連携している全サービスが危険にさらされる、という特性もあります。正しく使えば情シス担当者の負荷を大幅に下げられる技術ですが、誤った運用では逆にリスクが一点に集中します。

この記事では、SSOの仕組みと代表的な実装方式（SAML・OAuth・OpenID Connect）、見落とされがちなセキュリティリスクと対策について、現場で使えるレベルで解説します。

シングルサインオン（SSO）とは？

シングルサインオン（Single Sign-On、SSO）とは、一度の認証で複数のシステムやサービスにアクセスできる仕組みです。

「Microsoft 365にログインしたら、SharePointもTeamsもOutlookも、改めてパスワードを入力せずに使える」という状態がまさにSSOです。

なぜSSOが必要か

社員が日常的に使うクラウドサービスの数は、ここ10年で激増しました。Slack、Salesforce、freee、kintone、Zoom……業種によっては10～20種類のサービスを使いこなしている企業も珍しくありません。

サービスごとに異なるパスワードを設定・管理するのは現実的ではなく、その結果として起きるのが「パスワードの使い回し」です。使い回しは、1つのサービスの情報漏洩が他の全サービスへの不正アクセスに直結するリスクを生みます。

SSOを導入すると：
・ユーザーは覚えるパスワードが1つで済む
・IT部門はアカウント管理を一元化できる
・退職者対応がSSOのアカウント停止1つで完結する

SSOの主な仕組みと実装方式

SSOを実現する方式は複数あります。代表的な3つを解説します。

1. SAML（Security Assertion Markup Language）

SAMLは、XMLベースのオープン標準規格です。企業向けのSSOで広く使われており、Active DirectoryやMicrosoft Entra IDとの連携に向いています。

登場人物は2つです：
・IdP（Identity Provider / アイデンティティプロバイダー）： ログインを確認する側。例：Microsoft Entra ID、Okta、Google Workspace
・SP（Service Provider / サービスプロバイダー）： サービスを提供する側。例：Salesforce、kintone、Slack

仕組みの流れはこうです。ユーザーがSPにアクセスすると、SPがIdPにリダイレクトします。IdPでの認証が通ると、SAMLアサーション（認証情報を含むXML文書）がSPに返され、SPがそのアサーションを検証してアクセスを許可します。

2. OAuth 2.0

OAuth（オーオース）は、「認可（Authorization）」のための標準プロトコルです。本来は「あるサービスが別のサービスのデータにアクセスする権限を委譲する」ための仕組みで、厳密には認証プロトコルではありません。

「Googleアカウントでログイン」ボタンを押したとき、GoogleがそのサービスにあなたのGoogleアカウント情報へのアクセスを「認可」しているのがOAuth 2.0の仕組みです。

3. OpenID Connect（OIDC）

OpenID Connect（OIDC）は、OAuth 2.0の上に「認証（Authentication）」機能を追加した標準プロトコルです。現在、多くのWebサービスがOIDCを採用しており、「Googleアカウントでログイン」「Microsoftアカウントでログイン」の大部分はOIDCで実装されています。

SAMLとOIDCの使い分け：
・SAML： 大企業向けの社内システム連携に強い。古いエンタープライズ製品との互換性が高い
・OIDC： モバイルアプリ・Web API向けに設計されており、現代的なサービスに適している

SSOのセキュリティリスク

SSOは利便性が高い一方で、正しく運用しないと深刻なリスクをはらんでいます。

【リスク1】IdPが突破されると全サービスが危険にさらされる

SSOの最大のリスクは「単一障害点（Single Point of Failure）」です。IdP（認証を担うサーバーやサービス）への攻撃が成功すると、そのIdPに連携している全サービスへの不正アクセスが可能になります。

「ひとつの鍵を盗まれたら、全部の部屋に入られる」状態です。

これを防ぐ最も重要な対策が、IdPアカウントへの多要素認証（MFA）の必須化です。パスワードだけでなく、認証アプリやハードウェアキーを組み合わせてIdPへのログインを守ることが前提条件になります。

【リスク2】セッション管理の甘さによるセッションハイジャック

SSOでは、認証後にセッショントークンが発行されます。このセッションの管理が甘いと、攻撃者が有効なセッションを奪う「セッションハイジャック」が成立してしまいます。

対策として、認証後にセッションIDを必ず再発行すること（セッションの再生成）と、セッションの有効期限を適切に設定することが重要です。

【リスク3】SAMLアサーションの検証漏れ

SAML実装のバグとして歴史的に多いのが、アサーションの署名検証を適切に行っていないケースです。検証が不十分だと、攻撃者が偽のSAMLアサーションを作成して任意のユーザーになりすませます（SAMLインジェクション）。

独自にSAMLを実装するのではなく、実績のあるライブラリや製品を使うことが基本原則です。

【リスク4】リダイレクトURLの検証不備（オープンリダイレクト）

OAuth 2.0やOIDCでは、認証後にリダイレクトするURLをあらかじめ登録します。このリダイレクト先の検証が不十分だと、フィッシングサイトに誘導される「オープンリダイレクト」攻撃が成立します。

IdP側でリダイレクト先のURLを厳密にホワイトリスト管理することが必須です。

具体的な防御手順

1. IdPアカウントにMFAを必須化する

IdPが攻撃の最重要ターゲットです。管理者アカウントはもちろん、一般ユーザーアカウントにも多要素認証を必須化します。

Microsoft Entra ID（旧Azure AD）であれば条件付きアクセスポリシーで、Oktaであれば認証ポリシーで、強制的にMFAを要求する設定が可能です。

2. セッションのタイムアウト設定を適切に行う

SSOのセッション期間が長すぎると、端末を紛失したときや攻撃者にセッションを奪われたときのリスクが大きくなります。

# Microsoft Entra管理センターでのサインイン頻度設定（条件付きアクセス）
# [保護] → [条件付きアクセス] → [セッション] → [サインインの頻度]
# 推奨値：
#   機密システム（財務・人事） : 1時間
#   一般業務システム            : 8時間（1営業日）
#
# [永続ブラウザーセッション] → [非永続的] に設定することで
# ブラウザを閉じるたびにセッションを終了させられる

3. IdPのアクセスログを定期的に確認する

SSOのIdPはアクセスログが集中する場所です。失敗したログイン試行、普段と異なる場所・時間帯からのログインなどを定期的に確認します。

Microsoft Entra IDであれば「サインインログ」、Google Workspaceであれば管理者コンソール→レポート→監査で確認できます。

4. SPとIdPの連携設定を棚卸しする

SSOに連携しているサービスの一覧を定期的に棚卸しし、使われていないサービスの連携を解除します。退職者が使っていたサービスとの連携も見直しの対象です。

# Google Workspaceで連携アプリを確認する方法
# 管理者コンソール → セキュリティ → APIコントロール → アプリのアクセス制御
# 「信頼できるアプリ」として登録されていないサービスは要確認

中小企業でも今日からできること

「うちはまだSSOを導入していない」という企業でも、すぐに取り組めることがあります。

・Google WorkspaceまたはMicrosoft 365の管理者アカウントにMFAを設定する： これら2つは、多くの企業でSSOの起点になっています。管理者アカウントを最初に守ることが最優先です
・Googleアカウントのサードパーティアプリ連携を確認する： Google管理コンソール → セキュリティ → APIコントロールで、どのサービスがGoogleアカウントに連携しているか一覧確認できます
・使っていないOAuth連携を削除する： 試しに連携したまま放置しているサービスはセキュリティリスクです。定期的に棚卸しして不要な連携を切りましょう
・一般ユーザーにもMFAを展開する： 管理者だけでなく、全社員のアカウントにMFAを適用することで、SSOのIdPへの不正アクセスリスクを大幅に低下させられます

正式なSSOソリューション（Okta、Microsoft Entra IDなど）を導入する前の段階でも、IdPとして機能しているGoogleやMicrosoftのアカウント保護を徹底することが、実質的なSSOセキュリティの第一歩です。

よくある誤解と注意点

【誤解1】SSOを導入すれば安全になる

SSOはパスワード管理のリスクを下げますが、IdPが突破されれば全サービスが危険にさらされます。SSOは「セキュリティを強化するための道具」であり、正しく運用しなければ逆にリスクが集中します。導入と同時に、IdPの保護を最優先で強化してください。

【誤解2】OAuthはログイン（認証）のための仕組みだ

OAuth 2.0は本来「認可（Authorization）」のプロトコルです。「このアプリがあなたのGoogleドライブにアクセスする許可を与えますか？」という権限委譲のための仕組みで、「あなたが誰かを確認する」認証はOpenID Connect（OIDC）が担います。設計や会話の中で意識して使い分けることが重要です。

【注意】SSOのIdPを自前構築する場合は専門家に相談する

SAML・OAuth・OIDCの実装は、仕様が複雑で脆弱性の入り込みやすい領域です。独自実装を選択する場合は、セキュリティ専門家によるコードレビューと脆弱性診断を必ず受けてください。詳細は法律・セキュリティの専門家にご確認いただくことを推奨します。

本記事のまとめ

SSOは、パスワード管理の複雑さを解消し、情シス担当者の運用負荷を下げる有力な手段です。しかし「IdPの保護」と「セッション管理」を怠ると、便利さがそのままリスクに変わります。

今使っているIdP（GoogleやMicrosoftのアカウント）を正しく守ることが、中小企業でもすぐ取り組めるSSOセキュリティの出発点です。

認証・認可の基礎概念については、認証と認可の違いとは？混同しやすい2つの概念を具体例でわかりやすく解説も合わせてご覧ください。

多要素認証の詳細な導入手順については、多要素認証（MFA）とは？仕組みと導入手順をわかりやすく解説も参考になります。

Linuxサーバーの認証強化（PAMを使ったパスワードポリシー設定）については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。