SSOとアカウントプロビジョニングの違い

SSOはログインをまとめる仕組み、アカウントプロビジョニングは利用先のアカウントを整備する仕組み です。ログインできることと、アカウントや権限が適切に管理されていることは、別々に確認する必要があります。

ここではSaaSに限らず、社内システム、自社開発アプリ、クラウドサービスを含めて説明します。規格はSAML 2.0、OpenID Connect 1.0、SCIM 2.0を対象とし、参考資料は2026年11月1日に確認しています。

目的と役割の違い

SSO（Single Sign-On：シングルサインオン）は、一度の認証を基に複数のアプリを利用できるようにします。IdP（Identity Provider：認証を担当する基盤）を信頼して、アプリが認証結果を受け取る構成が代表例です。アクセス条件によって再認証が必要な場合もあります。

アカウントプロビジョニングは、ユーザーの作成、属性更新、グループへの所属などを管理します。退職時などに利用を停止・削除する処理はデプロビジョニングと呼びます。手作業でも実施できますが、SCIMや製品固有API、ディレクトリ連携による自動化が運用負担の軽減に役立ちます。

どちらも業務上のアクセス権を自動的に正しくするものではありません。部署と権限の対応、承認、定期的な棚卸しは別途設計します。

同じID基盤がSSOとプロビジョニングを提供しても、連携経路は別です。

人事情報・ディレクトリ → ID基盤
利用者 → アプリ → IdPで認証 → アプリが認証結果を検証
ID基盤のプロビジョニング機能 → SCIM等の管理API → アプリのユーザー・グループ

オンプレミスのアプリでは、管理APIへの到達性や中継エージェントが必要になることもあります。認証経路が通るだけでは、管理APIも利用できるとは限りません。

例えば、社内ポータルへのログインをIdPにまとめても、ポータルの既存ユーザー、部署、権限はそのまま残ります。新規ユーザーは手動登録する構成も、初回ログイン時にJITで作成する構成もあります。

JIT（Just-in-Time）プロビジョニングは、認証結果を使って利用開始時にアカウントを作るアプリ側の機能です。SSO規格だけで一律に保証される機能ではなく、属性更新やグループ反映の範囲も製品によります。退職した利用者がもうログインしなければ、JITだけでは退職処理を起動できません。

入社前に利用先のアカウントを準備し、ログインにはSSOを使えます。異動や退職もID情報を起点に利用先へ反映できます。ただし同期失敗や待ち時間があるため、即時反映を前提にしない設計が必要です。

SSOだけでは、利用先アカウントの削除、全ユーザーの属性の継続更新、データの所有者変更は保証されません。IdPで認証を禁止しても、ローカルパスワード、APIトークン、既存セッションが残る場合があります。

プロビジョニングだけでは、ログインを共通化したり、多要素認証を実施したりできません。また、アカウントを無効化した時に全セッションが失効するかは、利用先の実装を確認する必要があります。

SAMLとOIDCは認証連携の代表的な規格です。OAuth 2.0は主に認可のフレームワークで、OIDCはその上に認証の仕組みを定義します。SCIMはユーザーやグループの管理APIを標準化します。

SSOとSCIMは独立しており、両方の導入が必須ではありません。例えば少人数の業務アプリでSSOと手動管理を組み合わせる構成も、SSO未対応のアプリでプロビジョニングだけを自動化する構成もあります。人数、退職処理の期限、アプリの対応状況から判断します。

アクセス判断全体との関係は、NISTのゼロトラストアーキテクチャも参考になります。

SSOは認証、プロビジョニングはアカウント管理を担います。併用すると入社から退職までの運用を整えやすくなりますが、権限やセッションの扱いは利用先ごとに検証します。