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

シングルサインオン（SSO）は、ある認証基盤で本人確認を行い、その結果を複数のシステムやサービスで使えるようにする仕組みです。ログイン回数を減らせる一方で、認証の起点が集約されるため、設計を誤ると影響範囲も広がります。導入判断では、ログインが楽になるかどうかではなく、どの連携方式を使:contentReference[oaicite:0]{index=0} href="/saas-2023_mkt_tst" target="_blank" rel="noopener">SaaSや社内システムを横断して使っており、認証ルールをそろえたい環境です。反対に、連携非対応の古いシステムが多い環境では、対象範囲を段階的に絞らないと運用が複雑になりやすくなります。

シングルサインオンとは

シングルサインオンとは、ある認証基盤で本人確認を行い、その結果を他のシステムやサービスでも利用できるようにする仕組みです。利用者はサービスごとに毎回認証情報を入力する回数を減らしやすくなり、管理者は認証の入口を集約しやすくなります。

実装では、認証基盤がログイン結果をサービス側へ渡し、各サービスがその結果をもとにログイン状態を成立させます。代表的な連携方式には、SAML認証、OpenID Connect、Kerberos などがあります。

SSOが成立する前提

• 認証の役割を担う基盤があり、各サービスがその結果を受け取れること
• サービス側でセッションやトークンを発行し、一定期間ログイン状態を維持できること
• 再認証の条件、有効期限、リスク時の追加認証を一貫して設計できること

このため、SSOの検討では「どの方式で連携するか」だけでは足りません。ログイン状態をどう維持するか、再認証をどの条件で求めるか、障害時にどの業務を優先的に継続させるかまで決めておく必要があります。

SSOとID管理の関係

SSOはログイン経路をまとめる仕組みですが、実務ではIDaaSやID管理基盤と組み合わせて使うことが多くなります。アカウントの発行・変更・停止、多要素認証の適用、ログ監視まで含めて扱うことで、導入後の管理を安定させやすくなります。

認証と認可の違い

SSOを理解するうえで外せないのが、認証と認可の違いです。

• 認証：その利用者が本人であることを確認すること
• 認可：確認された利用者に、どこまでアクセスを許可するかを決めること

SSOで集約されるのは原則として認証です。サービスに入った後の閲覧権限、更新権限、管理者権限などの扱いは、各サービスの権限モデルに従います。つまり、SSOを導入しても権限設計が自動で整理されるわけではありません。誰に何を許可するのか、例外をどう扱うのかは別に設計します。

シングルサインオンの主な方式

SSOを実現する方式は複数あります。使っているサービス、社内環境、将来の拡張方針によって選び方が変わります。

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

SAMLは、XMLベースのアサーションを使って、認証基盤とサービスの間で認証結果や属性情報をやり取りする方式です。企業向けのSaaSで広く使われています。一般に、認証基盤をIdP、認証結果を受け取る側をSPと呼びます。

確認したい点

• 署名や証明書の更新運用
• メールアドレス、ユーザーID、部署などの属性の受け渡し方
• SP開始とIdP開始のどちらを基本導線にするか
• セッション期限、再認証条件、ログアウト挙動

適しやすい場面

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

OpenID ConnectとOAuth 2.0

OpenID Connectは、OAuth 2.0を土台にした認証レイヤーです。OAuth 2.0自体は認可の枠組みであり、OpenID Connectはその上で「誰がログインしたか」を扱えるようにした仕様です。モダンなWebアプリやAPI連携で使われることが多く、SAMLより実装しやすい場面もあります。

確認したい点

• IDトークン、アクセストークン、リフレッシュトークンの有効期限と失効設計
• どの属性をどこまで渡すか
• API保護の方針とトークンの保管方法
• Web、SPA、ネイティブアプリなどクライアント種別ごとの実装要件

この方式は柔軟ですが、トークンの扱いを誤ると成りすましの余地が生まれます。ブラウザ、端末、アプリ側の保護まで含めて設計したほうが安全です。

Kerberosによるドメイン内SSO

Kerberosは、チケットを使って本人確認を行う方式で、Windowsドメイン環境の社内システムと相性が良くなります。社内ファイルサーバーや社内Webなど、ドメイン参加端末が中心の環境で使われることが多くなります。

ただし、クラウドサービス中心の環境ではSAMLやOpenID Connectが主軸になりやすく、Kerberos単体で全体を統一できるとは限りません。社内環境向けの方式として切り分けて考えたほうが整理しやすくなります。

エージェント・代理入力・リバースプロキシ方式

連携非対応の既存システムが残る場合は、エージェント方式、代理入力方式、リバースプロキシサーバーを前段に置く方式が候補になります。

• エージェント方式：対象サーバーへモジュールを組み込み、認証基盤と連携する
• 代理入力方式：ログイン画面へ認証情報を自動入力する
• リバースプロキシ方式：前段の中継サーバーで認証し、各サービスへ渡す

これらは古いシステムを延命しやすい一方で、画面変更への追従、性能、可用性、例外運用の負担が増えやすくなります。恒久策として使うのか、移行までの暫定策として使うのかを分けて判断したほうが失敗しにくくなります。

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

ログインの手間を減らしやすい

サービスごとに認証情報を入力する回数を減らせるため、業務の中断が減りやすくなります。PCだけでなくスマートフォンやタブレットの利用でも差が出やすい領域です。

認証ルールを集約しやすい

認証の入口を集約すると、多要素認証や条件付きアクセスを一か所で適用しやすくなります。特に、VPNや管理画面など、突破されたときの影響が大きい入口では効果が出やすくなります。

アカウント停止や変更を反映しやすい

SSOとID管理が連携できると、異動や退職に伴うアカウント停止をまとめて反映しやすくなります。サービスごとに残存アカウントが残る状況を減らしたい場合は、この点が導入効果になりやすくなります。

認証ログを集約しやすい

不審なログイン、失敗の増加、管理設定の変更などを一か所で追いやすくなるため、監査や事故調査でも扱いやすくなります。どのログを見たいのかを先に決めておくと、製品選定も進めやすくなります。

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

認証基盤が突破されると影響範囲が広がる

SSOでは認証が集約されるため、認証基盤が侵害された場合の影響は大きくなります。とくに管理者権限を持つアカウントは、通常利用者と分けて保護したほうが安全です。

先に整えたい対策

• 管理者アカウントへのMFA必須化
• 管理操作を行える端末やネットワークの限定
• 権限変更や連携設定変更の監査ログとアラート

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

利用中のサービスがSAMLやOpenID Connectに対応していない場合、すべてを一度にSSO化できるとは限りません。対象範囲を棚卸しし、どこまで標準連携で進められるか、どこから例外対応が必要になるかを先に見分けます。

障害時の業務影響が大きい

認証基盤に障害が起きると、SSO対象サービスへ広く影響が出ることがあります。冗長化、フェイルオーバー、緊急用アカウント、代替ログイン手順を事前に決めておかないと、復旧までの判断が遅れやすくなります。

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

SSOはログインをまとめる仕組みですが、ログアウト挙動はサービスごとに差が出ます。認証基盤側でログアウトしても、サービス側やブラウザ側のセッションが残る場合があります。共有端末の利用、セッションタイムアウト、再認証条件まで含めて設計しておくと混乱を減らしやすくなります。

セッションやトークンが盗まれる余地がある

認証後は、サービス側でセッションやトークンが発行され、一定期間ログイン状態が維持されます。フィッシングやマルウェアでこれらが盗まれると、パスワードが守られていても成りすましが成立することがあります。認証方式だけでなく、端末対策や異常検知まで組み合わせる必要があります。

導入前に決めておきたいこと

• 対象サービスの棚卸しと、各サービスの対応方式の確認
• 認証基盤を何にするか
• 認証と認可をどう分担するか
• 退職・異動時のアカウント停止をどう反映するか
• 障害時に優先継続する業務は何か
• 監査ログを誰が確認し、どの条件でアラート化するか

導入を急いでも、この設計が曖昧だと運用で詰まりやすくなります。全サービス一斉ではなく、影響が大きいサービスから段階的に広げる進め方のほうが現実に合いやすくなります。

システム選定のポイント

• 利用したいサービスがSAMLやOpenID Connectに対応しているか
• 社内中心か、SaaS中心か、混在環境か
• クラウド、オンプレミス、ハイブリッドのどれで運用するか
• 冗長化、SLA、障害時サポートの内容
• MFA、条件付きアクセス、管理者保護、監査ログの有無
• アカウント作成・停止の自動連携のしやすさ

見落としやすい観点

退職者アカウントを確実に止められるか

ログインの楽さだけを見て選ぶと、運用上の穴が残りやすくなります。各サービスへのアカウント停止が確実に反映される仕組みまで見たほうが安全です。

ログが判断に使える粒度で取れるか

不審ログイン、管理設定の変更、権限変更を追いたいなら、取得できるログの粒度と保管方法を先に確認します。集約できても見分けられないログでは、事故対応に使いにくくなります。

まとめ

シングルサインオンは、ログインを減らすための仕組みであると同時に、認証を集約して管理しやすくする仕組みです。導入すると、利便性、認証ルールの統一、ログ集約の面で効果が出やすくなります。

一方で、認証基盤が重要インフラになるため、MFA、監査ログ、冗長化、障害時手順まで含めて設計しないと、便利さだけが先行してリスクが残ります。導入判断では、方式、対象範囲、権限設計、障害対策をセットで見たほうが失敗しにくくなります。

FAQ：シングルサインオンの基礎と導入