顧客ごとに異なるIdPをB2B SaaSで安全に受け入れる方法
顧客ごとに異なるIdPやプロトコルを利用するB2B SaaS向けに、マルチテナントSSOを安全かつ拡張可能に設計する方法を解説します。
エンタープライズ顧客にSSOを提供する際、最初に直面するのは、すべての顧客が同じIdPを使っているわけではないという現実です。Microsoft Entra IDを使う企業もあれば、OktaやGoogle Workspaceを使う企業もあります。接続方式もOIDCとSAMLに分かれ、ユーザーの作成・失効にはSCIMを求められることがあります。
顧客が増えるたびに製品コードへ例外を追加すると、最初の契約には対応できても、運用の複雑さとセキュリティリスクが同時に増えます。B2B SaaSに必要なのは、複数のIdPを単に接続する機能ではなく、顧客ごとの認証境界を維持するマルチテナント戦略です。
一つの共通SSO設定が危険な理由
共通設定に複数顧客のドメイン、証明書、クライアントシークレットをまとめると、ある顧客の変更が別の顧客のログインに影響する恐れがあります。メールアドレスだけでテナントを決める方式も、ドメイン所有権を確認しなければ誤った組織へ接続される危険があります。
まず、接続設定、許可ドメイン、プロトコル、MFAポリシー、管理者権限を顧客ごとに分離します。ドメイン登録前にはDNSなどで所有権を検証してください。詳しい原則はドメイン検証とSSOセキュリティで確認できます。
OIDCとSAMLを同じ運用モデルで管理する
プロトコルの実装は異なっても、運用項目は標準化できます。接続ごとに次の情報を明示しましょう。
- 所有する顧客と担当管理者
- 発行者、メタデータ、リダイレクトURI
- 証明書またはクライアントシークレットの有効期限
- テスト完了状態と最終変更履歴
- 障害時の緊急ログインとロールバック手順
新しいアプリではOIDCが扱いやすい場合が多い一方、既存の企業環境ではSAMLの要件も依然として多くあります。選定基準はOIDCとSAMLの比較を参考にしてください。
ログイン後のライフサイクルも接続する
SSOに成功しても、アカウント管理は完了しません。入社時の作成、異動時の権限変更、退職時の停止が手作業なら、休眠アカウントや過剰な権限が残ります。顧客ごとにSCIM接続を分離し、グループをアプリのロールへ対応させ、認証とプロビジョニングが同じテナント境界に従うようにします。
SSO非対応の既存アプリにはSWAを補完手段として利用できますが、パスワード保管ポリシーとアクセスログを別途管理する必要があります。また、管理者や高リスク操作にはMFAを適用し、連携先IdPのポリシーの空白を減らすことが重要です。
顧客追加を開発プロジェクトにしない
拡張可能な構成では、顧客管理者が自社のOIDC/SAML接続を設定し、検証テスト後に有効化し、SaaS運営者は全体の状態と監査履歴を確認します。顧客別の分離原則はマルチテナントIdPの分離で詳しく解説しています。
AxiPassは、SaaS企業が顧客ごとのOIDC/SAML SSO、SCIM、MFA、SWA接続を一つのマルチテナント環境で運用できるよう支援します。顧客ごとに異なるIdPを製品コードの例外ではなく、標準化された接続単位として管理し、エンタープライズの導入を迅速かつ安全に進めましょう。
