IT用語集 2023/06/07

シングルサインオンとは？仕組みやメリットを解説

Q: シングルサインオンとは何ですか

シングルサインオンは、一度のログインで複数のシステムやサービスを利用しやすくする仕組みです。ログイン作業を減らしつつ、認証（本人確認）を認証基盤に集約して、MFAや条件付きアクセスなどのルールを適用しやすくします（権限＝認可の設計は別途必要です）。

近年、テレワークの普及やクラウドサービスの業務利用など、働き方は急速に変化しています。働き方の変化に伴い、一人ひとりが利用するシステム・サービスの数も増え、管理すべきIDやパスワードも膨大になりつつあります。そのような中、利便性とセキュリティを両立するための仕組みとして利用されるものがシングルサインオン（SSO）です。

ただし、SSOは「ログインが楽になる仕組み」というだけではありません。認証の入口が集約される分、設計を誤ると影響範囲が大きくなります。この記事では、シングルサインオンの概要から仕組み、メリット・デメリットに加えて、方式ごとの向き不向き、導入時に押さえるべき前提条件、運用・監視・障害対策まで、実務判断に使える形で整理します。

シングルサインオンとは

シングルサインオン（SSO）とは、ある認証基盤で本人確認（認証）を行い、その結果を他のシステムやサービスでも利用できるようにする仕組みです。たとえばSAMLやOpenID Connectなどの連携方式を使い、認証基盤（IdPなど）でログインした結果（アサーション／トークン）をサービス側が受け取ってログイン状態を成立させます。

近年では、一人で複数のIDやパスワードを管理することが当たり前となっていますが、数が増えるほど管理は難しくなり、パスワードの使い回しや弱いパスワード設定などのリスクも増えがちです。シングルサインオンを利用すれば、ユーザーはログインの手間を減らしやすくなります。管理者側も、認証（本人確認）を認証基盤に集約し、MFAや条件付きアクセスなどのルールを適用しやすくなります。一方で、認可（権限）は原則として各サービス側の権限モデルに従うため、権限設計は別途整理が必要です。

SSOが成立するための前提

SSOは「ログインをまとめる」体験として見えますが、実装上は次の前提で成立します。

ユーザーを確認する認証の役割を担う基盤があり、各サービスがその結果を信頼して受け取れる
サービス側が受け取った認証結果に基づいて、セッションやトークンを発行し、一定期間ログイン状態を維持できる
ログイン状態の期限、再認証のタイミング、リスク時の追加認証などのルールが一貫して設計されている

この前提を踏まえると、SSO導入の検討では「どの方式で連携するか」だけでなく、「ログイン状態をどう維持し、どんな条件で再認証させるか」「障害時に業務を止めないために何を用意するか」といった運用設計までが重要になります。

SSOとID管理の関係

SSOは「ログインをまとめる」仕組みですが、実際にはID管理（IAM）や認証基盤（IDaaS、Active Directoryなど）とセットで運用されることが多い仕組みです。SSO単体ではなく、IDの発行・変更・削除（ライフサイクル）や、多要素認証（MFA）、ログ監視などと組み合わせて安全に使える状態に近づきます。

よくある誤解

SSOを入れれば権限管理も自動的に整理される
SSOを入れればパスワード問題は完全に解決する
SSOを入れればログアウトも一括で完全にできる

実際には、権限（認可）の設計は別に必要であり、パスワードに依存しない認証へ移行する場合も段階設計が必要です。また、ログアウト挙動は方式やサービスごとに差が出やすく、SSO側でログアウトしてもサービス側やブラウザ側のセッションが残るなど、期待どおりに「一括で完全終了」にならない場合があります。期待値の調整と運用ルールが欠かせません。

認証と認可

シングルサインオンを含むアクセス制御を考える際には、認証と認可の違いを理解しておくことが重要です。

認証：ユーザーが本人であることを確認すること
認可：ユーザーに権限を付与し、どこまでアクセスできるかを決めること

あなたはAさんですかと確認するのが認証であり、AさんはファイルXを閲覧できます、Aさんは設定変更ができますといった閲覧権限・読み書き権限・管理者権限などを割り当てるのが認可です。重要なファイルやシステムへのアクセス権限を適切に管理することは、セキュリティ対策として欠かせません。

SSOでは認証をまとめられますが、認可はサービス側の権限モデルに従います。つまり「入れるかどうか」を判断するには、次の2つを分けて考える必要があります。

認証：どの方式で、どの条件で本人性を確認するか
認可：どのグループ・役割に、どの操作を許すか。例外をどう扱うか

SSOを活用し、サービスごとに適切な認証と認可を行うことで、利便性を損なわずにセキュリティを高めやすくなります。

シングルサインオンの方式と仕組み

シングルサインオンを実現する方式は複数あります。自社の環境や利用するシステム・サービスにより適切な方式は異なるため、それぞれの仕組みと、導入時に確認すべき前提条件を押さえておきましょう。

SAMLによるフェデレーション

SAML（Security Assertion Markup Language）は、XMLで表現されるアサーション（認証の結果や属性など）を用いて、認証基盤とサービスの間で情報を連携するための規格です。SSOの文脈では、IdPでの認証結果をSAMLアサーションとしてSPに渡し、サービス側のログイン状態を成立させます。

一般的には、認証側の基盤をIdP（Identity Provider）、認証される側のクラウドサービスをSP（Service Provider）と呼びます。ユーザーがIdPで認証されると、署名などで検証可能な形でSAMLアサーションがSPへ渡され、サービス側でログイン状態が成立します。

導入時に確認すべきポイント

IdP側とSP側の署名・証明書の扱い、メタデータ更新の運用
名前IDや属性（メール、ユーザーID、部署、グループなど）の受け渡し方式と、同一性の突合ルール
SP開始とIdP開始のどちらを基本にするか。利用者導線と例外時の運用
セッションの有効期限、再認証要件、強制ログアウトの扱い

向いているケース

多くのSaaSをまとめてSSOしたい
社内の認証基盤を中心に、SaaSのログインルールをそろえたい

OpenID ConnectとOAuth 2.0

近年、WebサービスやモバイルアプリではSAMLに加えてOpenID Connect（OIDC）がよく利用されています。OAuth 2.0は本来、APIなどへのアクセス権（認可）を扱う枠組みです。OpenID Connect（OIDC）はそれを土台に、ユーザー認証の結果をやり取りする仕組み（IDトークンなど）を追加し、アプリが「誰がログインしたか」を確認できるようにした仕様です。OIDCではIDトークン（多くはJWT）などを用いて、アプリケーション側がユーザー情報や認証状態を確認します。

SAMLが企業向けSaaSで根強い一方、OIDCはAPI連携やモダンなWebアプリとの相性が良い点が特長です。SSO導入時はSAMLだけでなくOIDC対応も見ておくと、将来的な拡張がしやすくなります。

導入時に確認すべきポイント

トークンの種類（IDトークン、アクセストークン、リフレッシュトークン）と有効期限、失効の設計
スコープやクレームの設計、どの属性をどこまで渡すか
認可サーバーとリソースサーバーの分離、API保護の方針
クライアント種別（Web、SPA、ネイティブアプリ）ごとの推奨フローと実装要件

OIDCは連携しやすい反面、トークンの取り扱いを誤ると、盗まれたトークンで成りすまされるリスクが生じます。端末・ブラウザ・アプリ側のセキュリティ要件も含めて設計することが重要です。

Kerberosによるドメイン内SSO

Kerberos認証は、クライアントとサーバー間で身元確認を行うための仕組みで、Active Directory環境の社内システムでよく使われます。Kerberosでは、最初に認証に成功するとチケット（有効期限付き）を受け取り、そのチケットを使って他のサービス利用のためのチケットを取得することでSSOを実現します。

ここで注意したいのは、Kerberosはチケットを用いてネットワーク上の本人確認を行う仕組みであり、通信の暗号化まで自動的に常に担うわけではない点です。実際にどこまで（暗号化・完全性保護など）を行うかは、対象プロトコルや設定に依存します。ドメイン内のWindows統合認証と相性が良い一方、クラウドサービス中心の環境ではSAMLやOIDCが主軸になりやすいです。

向いているケース

社内ドメイン内でWindows統合認証を活かしたい
ファイルサーバーや社内Webなど、ドメイン参加端末が中心の環境

エージェントによる方式

エージェント方式は、Webサービスなどを公開するWebサーバーやアプリケーションサーバーにエージェントを組み込む方式です。エージェントを通して認証サーバーとやり取りし、SSOを実現します。

サーバー側へ組み込むため社内システムで採用されやすい方式です。リバースプロキシ方式と比べると、エージェントを導入した対象だけに適用できるため、既存環境への影響を小さく始めたい場合に選ばれることがあります。

導入時に確認すべきポイント

対応するアプリケーション・ミドルウェアの範囲とバージョン
アップデート時の追従、障害時の切り戻し手順
監査ログの取得粒度と、アプリ側ログとの突合のしやすさ

代理入力による方式

代理入力による方式は、ユーザーの代わりにログイン情報を代理で入力する方式です。クライアント側にエージェントを組み込み、サービスのログイン画面を検知して自動的にログイン情報を入力します。

古いアプリケーションでも対応しやすい一方で、画面構成変更に弱いなど運用面の注意が必要です。導入時は対象システムが将来も継続利用されるか、改修予定はあるかも含めて検討すると安全です。

注意点

画面変更でログインが失敗しやすく、運用保守が発生しやすい
パスワードの扱いが残りやすく、強固な認証へ移行しづらい

リバースプロキシによる方式

リバースプロキシ方式は、中継サーバーを介して認証を行うことでSSOを実現する方式です。ユーザーは各種サービスへアクセスする際にリバースプロキシサーバーを経由します。リバースプロキシサーバーで認証し、認証済みCookieなどを用いて各種サービスが利用できるようになります。

クライアントやサーバーへ直接手を加えなくてよい反面、アクセス経路として必ずリバースプロキシを通るようネットワーク設計を見直す必要があります。可用性設計（冗長化）やボトルネック対策も重要になります。

導入時に確認すべきポイント

対象通信が必ずプロキシを経由する設計になっているか
ピーク時の性能、セッション数、暗号処理の負荷見積もり
証明書管理、TLS終端の方針、ログ取得と保管

透過型の方式

いわゆる「透過型」と呼ばれることがある方式は、製品や構成によって実装が異なります。一般には、通信経路上の中継（プロキシ）やクライアント側の仕組みでログイン処理を代行し、サービス側にログイン状態を成立させます。どこで代行するか（経路上／端末上）、どの条件で成立するかは製品・構成に依存するため、導入前の検証が欠かせません。

ただし、どの範囲を透過的に扱えるか、対応アプリの条件、例外時の運用などは製品・構成により異なるため、導入前に検証が欠かせません。導入後に想定外の例外が増えると、運用が複雑になりやすい点にも注意が必要です。

シングルサインオンのメリット

シングルサインオンの導入は、利便性だけでなく、運用面・セキュリティ面の改善にもつながります。代表的なメリットを整理します。

セキュリティ強化につながる

業務で利用するシステムが増えるほど、弱いパスワード設定や使い回しが発生しやすくなります。SSOにより、ユーザーがサービスごとに別々のパスワードを入力する機会を減らせるため、使い回しや弱いパスワードが起きる余地を減らしやすい面があります。ただし効果は、MFAの有無、異常検知、認証基盤の保護などの設計・運用に大きく依存します。

また、認証を認証基盤に集約すると、MFA（多要素認証）や条件付きアクセス（端末状態・場所・リスク）を一元的に適用しやすくなる場合があります。ただし、実現できる制御範囲は認証基盤の機能や連携方式、サービス側の対応に依存するため、事前に要件と挙動を確認することが重要です。

効果が出やすい領域

VPNや管理画面など、突破されると影響が大きい入口の強化
退職・異動時のアカウント停止を一元化し、残存アカウントを減らす
認証ログを集約し、不審なログインを検知しやすくする

利便性が向上する

ログイン作業の回数が減り、必要なときにすぐサービスへアクセスできるようになります。PCだけでなくスマートフォンやタブレット利用が増える中、SSOは作業効率の改善に寄与します。

パスワード管理を効率化できる

パスワードを紙に書く、表計算ソフトで管理する、といった運用は漏えいリスクが高くなりがちです。SSOで個人の負担を減らしつつ、パスワードポリシーやMFAなどを認証基盤側で運用しやすくなります。

アカウント管理のルールを反映しやすい

SSOとID管理を連携できると、退職者のアカウント停止や異動による権限変更を一元的に反映しやすくなります。特に、利用サービスが増えるほど使われないアカウントが残るリスクが高まるため、IDのライフサイクル管理は重要です。

プロビジョニングの考え方

SSOはログイン経路の管理に強い一方で、アカウントの作成・削除が各サービスに残ったままだと、退職後もアカウントが残り続けるリスクがあります。サービス側のユーザー作成・無効化を自動化できる仕組み（プロビジョニング連携など）を設計に含めると、管理の抜けを埋めやすくなります。

シングルサインオンの注意点

シングルサインオンは多くのメリットをもたらしますが、同時に注意点も存在します。導入前に弱点を理解し、問題として表れにくい設計にしておくことが重要です。

突破された際の被害が大きくなる

SSOでは認証が集約されるため、認証基盤（IdPや認証サーバー）が侵害された場合、影響が広がりやすくなります。SSO導入時は、認証基盤そのもののセキュリティを特に重視する必要があります。

管理者が狙われる前提での保護

管理者アカウントのMFA必須化と、強度の高い方式の選択
管理者の操作を行える端末やネットワークを限定する設計
権限付与や連携設定変更など、重要操作の監査とアラート

SSO非対応のシステムが残ることがある

利用しているクラウドサービスがSAMLやOIDCに対応していない、社内システムの改修が難しい、といった理由でSSO化できない範囲が残ることがあります。導入前に対象範囲を明確にし、方式の対応状況と代替策（エージェント方式、リバースプロキシ方式、代理入力方式、段階導入など）を確認しましょう。

認証基盤の障害時に業務影響が大きい

認証基盤に不具合が生じると、SSO対象のシステム・サービスにアクセスできなくなる可能性があります。業務停止につながらないよう、冗長化、フェイルオーバー、メンテナンス計画、障害時の手順（緊急アカウント、代替ログイン）を事前に整備しておくことが重要です。

障害時に検討しておきたい例

認証基盤が停止した場合に、業務継続が必要なサービスは何か
緊急時のみ有効化できる管理用アカウントをどう管理するか
復旧までの暫定手順を誰が判断し、誰が実行するか

ログアウトの期待値がずれることがある

SSOはログインをまとめる仕組みであり、ログアウトはサービスごとに挙動が異なる場合があります。SSO側でログアウトしてもサービス側のセッションが残る、端末のブラウザにセッションが残る、といったズレが起きやすいため、セッションタイムアウトや端末共有時の運用ルールも含めて設計します。

トークンやセッションの盗難リスク

SSOは認証後、サービス側でセッションやトークンが発行され、一定期間ログイン状態が維持されます。このため、フィッシングやマルウェアなどによりセッション情報やトークンが盗まれると、パスワードが守られていても成りすましが成立するケースがあります。認証方式だけでなく、端末対策や異常検知も含めた設計が現実的です。

注意点への対策と設計の勘所

SSOの弱点は、認証基盤が重要インフラになる点です。以下の対策を組み合わせ、リスクを下げます。

多要素認証：特に管理者・特権操作は必須化する
条件付きアクセス：場所・ネットワーク・端末状態・リスクに応じて制御する
端末要件の強化：管理端末、暗号化、最新パッチ、EDRなどの前提を定める
監査ログとアラート：異常ログイン、権限変更、連携設定変更を監視する
冗長化・障害対策：高可用性、バックアップ、復旧手順を整備する
事前の棚卸し：対象サービスの対応方式、例外の洗い出し、段階導入計画を作る

なお、IPアドレス制限は「想定外の送信元からのアクセスを減らす」といった点で一定の効果はありますが、単独で万能ではありません。テレワークやモバイル利用が多い環境では運用が難しくなりやすいため、MFAや端末状態の確認などと組み合わせて設計するのが現実的です。

また近年は、フィッシング攻撃によってワンタイムコードやSMS認証が狙われるケースもあります。より強い対策として、FIDO2（パスキー）など公開鍵暗号を用いてサービスのドメインに結び付けて認証する方式（一般にフィッシング耐性が高いとされる）を検討する企業もあります。SSO導入時には、MFAを何にするかも重要な設計ポイントになります。