メインコンテンツへスキップ

シングルサインオンとは

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

シングルサインオン (Single Sign-On) とは、1 回の認証で複数のサービスやアプリケーションにアクセスできる仕組みです。ユーザーはサービスごとにパスワードを入力する必要がなくなり、パスワード疲れを大幅に軽減できます。企業の IT 環境では業務で使うクラウドサービスの数が多く、サービスごとに強いパスワードを個別に管理し続けることは現実的ではありません。技術的な詳細はSSO の用語解説もあわせて参照してください。

IdP と SP の関係

シングルサインオンの中核を担うのが IdP (Identity Provider: 認証プロバイダー) と SP (Service Provider: サービス提供者) の信頼関係です。IdP はユーザーの認証を一元的に管理し、SP は IdP が発行した認証トークンを検証してアクセスを許可します。代表的な IdP には Okta、Microsoft Entra ID (旧 Azure AD)、Google Workspace、OneLogin などがあります。

ユーザーが SP にアクセス
SP が IdP にリダイレクト
IdP で認証 (1 回だけ)
トークン発行
全 SP にアクセス可能

この仕組みにより、ユーザーは IdP に 1 回ログインするだけで、Slack、Salesforce、Jira、Confluence など連携する全サービスをシームレスに利用できます。

SAML vs OIDC の比較

シングルサインオンを実現するプロトコルとして、SAML 2.0 と OpenID Connect (OIDC) が広く使われています。どちらを選ぶかは利用シーンによって異なります。

項目SAML 2.0OpenID Connect (OIDC)
データ形式XMLJSON (JWT)
主な用途企業向け SaaS 連携Web / モバイルアプリ、ソーシャルログイン
ベースプロトコル独自仕様OAuth 2.0 の拡張
実装の複雑さ高い (XML 署名検証が複雑)低い (REST API ベース)
モバイル対応不向き (ブラウザリダイレクト前提)良好 (ネイティブアプリ対応)
採用例Salesforce、Workday、ServiceNowGoogle、GitHub、Auth0

企業の既存 SaaS 連携では SAML が依然として主流ですが、新規開発では OIDC を採用するケースが増えています。OIDC はセッショントークンの管理も JSON ベースで扱いやすく、開発者にとって実装のハードルが低い点が支持されています。

シングルサインオンのリスク

シングルサインオンは利便性とセキュリティの両面で大きなメリットがありますが、固有のリスクも存在します。

単一障害点

IdP が停止すると、連携する全サービスにログインできなくなる。2024 年の Okta 障害では多数の企業が業務停止に追い込まれた。

認証情報の集中リスク

IdP のアカウントが侵害されると、全連携サービスへの不正アクセスが可能になる。IdP アカウントには最も強力な保護が必要。

セッション管理の複雑さ

IdP と各 SP のセッション有効期限が異なると、ログアウトの不整合が発生する。シングルログアウト (SLO) の実装は技術的に難しい。

これらのリスクを軽減するため、IdP アカウントには多要素認証を必ず設定し、可能であればパスキーやセキュリティキーによるフィッシング耐性 MFA を採用します。また、IdP 障害時の緊急アクセス手段 (ブレークグラスアカウント) を事前に整備しておくことも重要です。企業のパスワードポリシーやスタートアップのセキュリティチェックリストで組織レベルでの導入指針を解説しています。

パスワード疲れの解消効果

シングルサインオンの最大の実務的メリットは、パスワード疲れの解消です。従業員が管理するパスワードの数が劇的に減少し、パスワードの使い回しや単純化といった危険な行動が抑制されます。「パスワードを忘れた」「ロックされた」という問い合わせは IT ヘルプデスクの定番業務ですが、認証の入口が 1 つに集まればその母数そのものが小さくなります。IAM 基盤と統合することで、入退社時のアカウント管理も一元化でき、退職者のアクセス権限が残り続ける「ゾンビアカウント」問題も解消されます。OAuth 権限のリスクもあわせて把握しておくと、認証基盤全体の設計に役立ちます。

現場での使用例

例えば、社内で使う SaaS が十数個まで増えた会社が、まず ID 基盤 (IdP) を 1 つ決め、チャット・文書共有・課題管理・ソースコード管理といった利用頻度の高いものから順に接続していく、という進め方があります。全部を一度に繋ぎ替えようとすると止められない業務が必ず出てくるため、影響範囲の小さいサービスで手順を確かめてから広げるのが現実的です。効果が最初に見えるのはヘルプデスクの負荷で、パスワードのリセット依頼が減り、退職者のアカウント停止も IdP 側の操作だけで完了するようになります。一方で IdP が止まればログインが一斉に止まるという弱点も同時に抱えることになるので、管理者用の緊急ログイン経路だけはシングルサインオンの外側に残しておくのが定石です。

関連用語

この記事は役に立ちましたか?