SaaS SSOとは？SAML・OAuth・OpenID Connectの違いとISMAP対応

2026/06/08 お役立ち記事

Check!

SSOは認証とID管理の集約設計
SAML・OAuth・OIDCは役割が異なる
ISMAP対応ではログ・権限・停止が重要

複数のSaaSを使うほど、利用者ごとのIDやパスワード、退職者アカウント、権限変更の管理は複雑になります。SaaS SSO（シングルサインオン）は、1つの認証基盤から複数のSaaSへログインできるようにする仕組みです。ただし、SSOは単なるログイン省略ではなく、SAML、OAuth、OpenID Connectなどの役割を分けて理解し、ID管理・多要素認証・ログ監査・アカウント停止まで含めて設計することが大切です。本記事では、特定のIdPサービスを推奨せず、SaaS利用時のSSOの考え方を技術基準と公的資料に沿って整理します。

SaaS SSOとは｜1つの認証で複数サービスに入る仕組み

SaaS SSOとは、利用者がIDプロバイダー（IdP）で認証を受け、その結果を複数のSaaSへ連携する仕組みです。NIST SP 800-63Cでは、利用者がサービスごとに別の認証情報を持たず、フェデレーションの仕組みで複数の依存先サービスを使える状態をSSOとして説明しています。SaaS側は、IdPから渡される認証結果や属性情報を確認し、利用者に必要な機能だけを許可します。

図1：SaaS SSOの基本構造

SSOの価値は、ログイン画面を減らすことだけではありません。利用者の追加・削除、退職時の停止、多要素認証、監査ログ、権限変更を中央で扱いやすくする点にあります。SaaSが増えた段階では、マルチテナントSaaSのセキュリティ基盤とあわせて、どの情報をIdPからSaaSへ渡すのかを整理する必要があります。

SAML・OAuth・OpenID Connectの違い

SSOの説明では、SAML、OAuth、OpenID Connectが同じ意味で語られることがありますが、役割は異なります。SAMLは主に企業向けのWeb SSOで使われる認証連携の方式です。OAuthは、あるサービスが別のサービスの機能やデータへ限定的にアクセスするための認可の枠組みです。OpenID ConnectはOAuth 2.0を土台に、利用者の本人確認を扱えるようにした認証レイヤーです。

図2：SSO・SAML・OAuth・OpenID Connectの関係

項目	主な目的	SaaSでの使われ方	注意点
SSO	複数サービスへのログイン体験をまとめる	IdPを中心にSaaSへの認証を連携する	仕組みそのものではなく設計全体を指す
SAML	認証結果をアサーションとして伝える	企業向けSaaSのWeb SSOで使われることが多い	証明書、属性、ログアウト設計を確認する
OAuth	APIなどへのアクセス権限を委任する	外部サービス連携やデータ取得で使う	OAuthだけで本人確認を済ませる設計は避ける
OpenID Connect	OAuth 2.0上で本人確認情報を扱う	Webアプリやモバイルアプリのログイン連携で使う	IDトークン、スコープ、リダイレクトURIを管理する

実務では「このSaaSはSAMLだけ対応」「このAPI連携はOAuth」「このアプリはOpenID Connect」というように、対象サービスごとに対応方式が分かれます。SSOを導入する前に、ログイン連携、権限連携、API連携を同じものとして扱わないことが大切です。

ISMAP要件でSSOが重視される背景

ISMAPは、政府情報システムで使うクラウドサービスのセキュリティ評価制度です。SaaSを業務で使う場合、利用者ID、権限、アクセスログ、認証強度をどのように管理するかが、情報保護の基礎になります。SSOは、利用者の本人確認を中央で扱い、SaaSごとのアカウント管理を統制しやすくするため、ISMAPを見据えたクラウド利用でも重要な検討項目です。

たとえば、利用者が退職した後も個別SaaSにアカウントが残ると、情報漏えいの入口になり得ます。SSOとID管理を組み合わせると、アカウント停止、権限変更、多要素認証、ログ確認を一元的に進めやすくなります。ISMAP全体の考え方は、SaaSのセキュリティ対策（ISMAP対応）で整理し、本記事ではSSOに関わる認証・ID連携へ絞って解説しています。

業種別SaaSでも、同じ考え方が必要です。医療機関では患者情報や診療周辺情報を扱うため、医療SaaSのSSO・ISMAP要件を個別に確認すると理解しやすくなります。経理部門では承認権限や振込関連の操作が関わるため、経理SaaSのID管理とあわせて、役割ごとのアクセス範囲を整理します。

SaaS SSO導入前に確認したい設計ポイント

SSOは導入して終わりではなく、対象SaaS、対象ユーザー、権限、ログ、停止手順まで決めてから運用します。個人事業主や小規模組織では、まず重要なSaaSだけを対象にする方法があります。中小企業では、入退社や異動に合わせたアカウント運用を整えます。中堅・大企業では、複数部門・複数拠点をまたぐ権限設計と監査ログの保管方針が重要になります。

図3：SaaS SSO導入前の5ステップ

確認項目	見るポイント	運用上の注意
対象SaaS	業務上重要なSaaSから優先する	全サービスを一度に移すと影響範囲が広がる
認証方式	SAML、OpenID Connectなどの対応を確認する	OAuth連携をSSOと誤認しない
利用者属性	氏名、メール、部署、役割などの連携範囲を決める	不要な属性を渡しすぎない
多要素認証	管理者や高権限ユーザーに強い認証を設定する	例外アカウントを残す場合は期限を決める
ログと停止	ログ保存期間、退職時の停止手順を決める	SaaS側に残るローカルアカウントも確認する

SaaS SSOを安全に運用する流れ

運用では、まず利用中のSaaSを棚卸しし、SSO対象にする範囲を決めます。次に、管理者、一般利用者、外部委託先などの利用者区分を整理し、どの区分に多要素認証を求めるかを決めます。さらに、部署異動や退職の際に、IdP側の停止だけでSaaS側の利用も止まるかをテストします。

特に注意したいのは、SSO対象外のローカルアカウントです。緊急用アカウントや初期管理者アカウントが残る場合、パスワード、保管者、利用履歴、見直し日を決めておきます。監査ログは「誰が、いつ、どのSaaSへ、どの権限で入ったか」を追える状態にし、インシデント時に確認できるようにします。

SSOは情報システム部門だけの作業ではありません。個人事業主なら利用サービスの棚卸し、中小企業なら入退社フローとの接続、中堅・大企業なら部門ごとの権限設計まで含めて考えます。SaaSの導入数が増えるほど、ID管理のルールを文書化し、定期的に見直すことが重要です。

よくある質問（FAQ）

Q. SaaS SSOとパスワード管理ツールは同じですか？

A. 同じではありません。パスワード管理ツールは認証情報を保管・入力する仕組みです。一方、SSOはIdPで認証した結果をSaaSへ連携し、ログインとID管理をまとめる考え方です。両方を組み合わせる場面もあります。

Q. OAuthに対応していればSSO対応と考えてよいですか？

A. OAuthは主に認可の枠組みです。本人確認を扱うログイン連携では、OpenID ConnectやSAMLなど、認証に使う方式を確認します。SaaSの設定画面で「OAuth連携」とだけ書かれている場合は、ログイン用途かAPI連携用途かを分けて見ます。

Q. SSOを入れれば多要素認証は不要ですか？

A. 不要とはいえません。SSOは認証を集約する仕組みであり、認証強度そのものはIdP側の設定に左右されます。管理者や高権限ユーザーには、多要素認証や条件付きアクセスを組み合わせる設計が現実的です。

Q. ISMAP対応のSaaSならSSO設定は確認しなくてもよいですか？

A. 確認は必要です。ISMAPはクラウドサービスのセキュリティ評価制度ですが、自社の利用者管理、権限設計、ログ確認まで自動で整うわけではありません。利用者側の運用ルールとSaaS側の設定をあわせて確認します。

Q. 小規模事業者でもSaaS SSOを検討すべきですか？

A. 利用するSaaSの数や扱う情報の重要度によります。少人数でも、経理、顧客管理、医療・法務関連など重要情報を扱う場合は、まず重要SaaSのログイン方式、二要素認証、退職時の停止方法を確認するとよいでしょう。

まとめ｜今日からできる3つのこと

SaaS SSOは、ログインを楽にするだけでなく、ID管理とセキュリティ運用を整えるための土台です。SAML、OAuth、OpenID Connectの違いを理解し、認証、認可、属性連携を分けて設計すると、SaaSが増えても管理しやすくなります。

利用中のSaaSを棚卸しし、重要度が高いものからSSO対応状況を確認する
SAML、OAuth、OpenID Connectの役割を分け、ログイン連携とAPI連携を混同しない
退職者停止、多要素認証、権限変更、ログ確認を運用フローとして文書化する

参考文献

National Institute of Standards and Technology「SP 800-63-4 Digital Identity Guidelines」2025年、https://csrc.nist.gov/pubs/sp/800/63/4/final、2026年6月6日取得
National Institute of Standards and Technology「SP 800-63C-4 Digital Identity Guidelines: Federation and Assertions」2025年、https://csrc.nist.gov/pubs/sp/800/63/c/4/final、2026年6月6日取得
National Institute of Standards and Technology「SP 800-145 The NIST Definition of Cloud Computing」2011年、https://csrc.nist.gov/pubs/sp/800/145/final、2026年6月6日取得
独立行政法人情報処理推進機構「クラウドサービス利用のためのセキュリティチェックシート」発行年・個別URLは入稿前確認、https://www.ipa.go.jp/security/、2026年6月6日取得
ISMAP運営委員会「政府情報システムのためのセキュリティ評価制度（ISMAP）」参照時点最新版、https://www.ismap.go.jp/、2026年6月6日取得

この記事に興味を持った方におすすめ