マルチテナントSSOでメールアドレスではなくユーザー識別子を使う理由

SSO連携における危険な誤解の一つが、「メールアドレスが同じなら同一ユーザー」と考えることです。メールアドレスは人には分かりやすい一方、氏名変更、ドメイン移行、再入社、外部スタッフへの切り替えで変わることがあります。複数顧客を一つのサービスで扱うB2B SaaSでは、異なるテナントに同じメールアドレスが存在する場合もあります。

近年のIAMは、ログインの成否だけでなく、アイデンティティのライフサイクルと最小権限を一体で管理する方向へ進んでいます。その出発点は、認証結果を正しいテナントと内部アカウントへ結び付けることです。誤ったマッピングは、配送ラベルの氏名だけを見て住所を確認しないようなものです。

メールアドレスは属性であり永続識別子ではない

メールアドレスをアカウントの唯一のキーにすると、変更時に新しいアカウントが作られたり、以前のアドレスを割り当てられた別人が既存権限を引き継いだりするおそれがあります。大文字・小文字の正規化だけでは解決できません。表示用メールアドレスと、変わらない外部識別子を分けて管理する必要があります。

プロトコルごとに安定したキーを使う

OIDCでは、issとsubの組み合わせでユーザーを識別するのが基本です。同じsubでも発行者であるissが異なれば、別ユーザーの可能性があります。SAMLでは、信頼するIdPとSP登録の境界内で永続性のあるNameIDを使い、その形式と変更方針を合意します。両プロトコルの違いは OIDCとSAMLの比較 をご覧ください。

SCIMのexternalIdは、顧客ディレクトリのオブジェクトとSaaS内部アカウントを結ぶために役立ちます。ログイン識別子とプロビジョニング識別子を別々に保存し、一つの内部ユーザーへ明示的に関連付ければ、メール変更後もライフサイクルを維持できます。詳しくは SCIM入門ガイド で解説しています。

識別キーにテナント境界を含める

マルチテナントSaaSの内部一意キーは、単純なメールアドレスではなく、tenant + identity provider + external subjectに近い形で設計します。認証レスポンスを処理するときは、リクエストを開始したテナント、登録済みIdP、発行者、対象アプリを併せて検証し、別顧客のアカウントとの混同を防ぎます。

顧客ドメインの確認も有効ですが、ドメイン所有権だけでユーザーの同一性を証明できるわけではありません。ドメイン検証のセキュリティガイド の制御と識別子マッピングは、別々の防御線として運用しましょう。

アカウント連携と変更には監査記録を残す

初回連携、識別子変更、手動統合、連携解除はいずれも高リスクな操作です。操作者、テナント、変更前後の値、理由、時刻を監査ログに残し、トークンや秘密情報は記録しません。自動マッピングの結果が曖昧な場合はメールアドレスから推測せず、ログインを停止して管理者の確認へ回す方が安全です。

リリース前チェックリスト

• OIDCはiss + sub、SAMLは合意した永続NameIDを基準にする • 内部キーにテナントとIdPの境界を含める • SCIM externalIdとログイン識別子の関連付けルールを文書化する • メール変更、再入社、同一メール衝突のシナリオをテストする • 手動アカウント統合に承認と監査ログを適用する

AxiPassで顧客ごとのアイデンティティ境界を一貫して運用

AxiPassは、SaaS企業がマルチテナント環境でOIDC、SAML、SCIM、MFA、そしてSSO非対応アプリ向けのSWAをまとめて運用できるよう支援します。顧客ごとの連携設定と監査記録を一元管理することで、ユーザー識別ルールを一貫して適用し、オンボーディング時の例外を減らせます。

安全なユーザーマッピングを基盤に顧客SSOを拡張するなら、AxiPassを 無料で始める。