Microsoft Entra External ID

解決する課題

• 顧客向けアプリにサインイン画面を自前で作ると、パスワード保管・ハッシュ・リセットまで自分で守る羽目になる → 認証基盤を外部に委譲して責任範囲を狭めたい
• 「Google でログイン」「Apple でログイン」のようなソーシャルログインを個別に実装したくない → フェデレーションをまとめて任せたい
• 取引先や協力会社のユーザーを自社ディレクトリに招きたいが、毎回アカウントを発行するのは重い → B2B 招待で相手の ID を借りて協働したい
• 社員向け（従業員テナント）と顧客向けの ID を混ぜたくない → 専用の外部テナントで住み分けたい

主要概念と用語

• External ID（外部 ID）: 自社の従業員ではない人（顧客・パートナー）向けの ID を扱う機能群の総称。従業員テナントの機能とはユースケースが分かれる
• 外部テナント（External tenant）: 顧客向け（CIAM）アプリ専用に作る、従業員テナントとは独立したテナント種別。サインアップ／サインインのブランディングやユーザーフローを外部ユーザー向けに最適化できる
• B2C（Business to Consumer）: 一般消費者がメールアドレスやソーシャルアカウントでセルフサインアップして使う形態。後継として External ID の外部テナントへ集約されつつある
• B2B（Business to Business）コラボレーション: 取引先など別組織のユーザーをゲストとして自テナントに招待し、相手の ID のまま自社リソースへアクセスさせる形態
• ユーザーフロー（User flow）: サインアップ／サインイン／パスワードリセットといった一連の画面と挙動を、コードを書かずに構成できる定義
• ID プロバイダー（IdP）連携: Google / Facebook / Apple や、SAML/OIDC の任意の外部 IdP をソーシャル／フェデレーションのサインイン元として追加する設定
• アプリ登録（App registration）: 認証を委ねるアプリの定義。リダイレクト URI やスコープを登録し、OAuth 2.0 / OpenID Connect でトークンを受け取る

仕様・制限・クォータ

• 認証プロトコル: OpenID Connect / OAuth 2.0 を中心に、外部 IdP 連携では SAML も利用できる
• テナント種別: 顧客向けは外部テナントを新規に作成して使う。従業員テナントとはサブスクリプション/課金や既定の振る舞いが分かれる
• B2B ゲスト: 招待したゲストはホームテナントの資格情報のままサインインし、こちら側ではゲストとして表現される
• MAU 課金の単位: 顧客向けの認証は**月間アクティブユーザー（MAU）**を基準に数える（具体的な無料枠・単価は変動するため公式の料金ページで要確認）
• カスタマイズ: ロゴ・配色・レイアウトなどブランディングや、属性収集の項目をユーザーフロー側で設定できる
• 上限値（連携できる IdP 数や属性数など）や提供地域は更新されうるため、設計時は最新の公式ドキュメントで確認する

内部の仕組み

External ID はアプリの「認証の出口」を肩代わりします。アプリ自身はパスワードを扱わず、トークンの検証だけを行います。

顧客（CIAM）サインインの流れ

1. アプリが External ID（外部テナント）へ OIDC/OAuth 2.0 で認証をリクエストし、ユーザーをサインイン画面へリダイレクト
2. ユーザーはローカルアカウント（メール＋パスワードやワンタイムパスコード）か、ソーシャル/フェデレーション（Google・Apple・任意の OIDC/SAML IdP）でサインインまたはセルフサインアップ
3. 必要なら多要素認証や、ユーザーフローで定義した属性収集（プロフィール入力など）を実施
4. External ID が ID トークン／アクセストークン（JWT） を発行し、アプリへ返す。アプリはトークンの署名と対象（aud）を検証してログイン成立

B2B コラボレーションの流れ

招待されたゲストは自分のホームテナントで認証され、その結果を招待側テナントが信頼してアクセスを許可します。資格情報の管理は相手組織側に残るため、退職などの失効も相手側に追従します。

設計パターン / ベストプラクティス

• 従業員テナントと外部テナントを分離: 社員用の ID と顧客用の ID を同居させず、外部テナントを切って混在リスクを避ける
• ユーザーフローでまず作る: 独自実装に走る前に、サインアップ／サインイン／パスワードリセットを標準のユーザーフローで構成し、足りない部分だけ拡張する
• ソーシャルログインで離脱を減らす: 顧客には Google / Apple など使い慣れた IdP を用意し、パスワード作成の心理的負担を下げる
• 属性は最小限だけ収集: サインアップで集める個人情報は必要最小限にし、後から段階的に集める（プログレッシブプロファイリング）
• B2B は招待で、B2C はセルフサインアップで: パートナーは B2B 招待、不特定多数の消費者は外部テナントのセルフサインアップ、と入り口を使い分ける

運用・監視

• サインインログ / 監査ログ: 外部ユーザーのサインイン成否やユーザーフローの実行を記録。Log Analytics / Microsoft Sentinel に流して長期保管・相関分析する
• 使用状況メトリクス: MAU の推移を把握し、課金見積もりと不審なスパイク（ボットによる大量サインアップなど）を監視
• ブランディングと文言の管理: ロゴ・配色・利用規約リンクなどはテナント設定として管理し、変更履歴を残す
• 障害時の切り分け: サインインできない場合は、ユーザーフロー・連携先 IdP・アプリのリダイレクト URI の順に確認する。認証失敗（サインイン不可）と認可不足（サインイン後の権限不足）を分けて見る

コスト

顧客向けの認証は**月間アクティブユーザー（MAU）**を基準に課金され、一定の無料枠の範囲なら追加費用なしで使える設計です。具体的な無料枠の規模や超過分の単価、追加機能（高度な MFA 手段など）の扱いは変動するため、断定せず公式の料金ページで確認してください。B2B コラボレーションのゲストも MAU としてカウントされる扱いが基本です。コスト最適化の要点は、不要なサインアップ（ボット）を抑えることと、MAU を増やす設計（過度な再認証）を避けることです。

セキュリティ

• パスワード保管を持ち込まない: 自前 DB にパスワードを保存せず、 External ID 側に資格情報管理を委ねて漏えい面を縮小する
• 多要素認証を有効化: 重要操作の前にメール/SMS/認証アプリなどで MFA をかけ、可能ならフィッシング耐性のある方式を選ぶ
• セルフサインアップの悪用対策: ボットによる大量登録やパスワードスプレーに備え、レート制限や CAPTCHA 相当の防御、異常検知を組み合わせる
• トークンは必ず検証: アプリ側で ID/アクセストークンの署名・発行元・対象（aud）・有効期限を検証し、生のクレームを無条件に信用しない
• B2B はゲストの権限を絞る: 招待したゲストには必要なアプリ/リソースだけを割り当て、棚卸し（アクセスレビュー）で不要権限を定期的に外す

関連サービス・比較

社員のサインインを担う Microsoft Entra ID（従業員テナント） が「内部の人」を対象にするのに対し、External ID は「外部の人（顧客・パートナー）」を対象にします。両者は同じ Entra ファミリーですが、テナント種別・課金・既定の挙動が分かれます。

ハンズオン / CLI例

外部テナントやユーザーフローの作成はポータルや専用 API が中心ですが、アプリ登録など基本操作は az CLI でも行えます。次は外部ユーザー向けアプリを登録し、ゲストを招待する例です。

# サインインして対象テナントを選択（外部テナントの ID を指定）
az login --tenant "<external-tenant-id>"

# 顧客向けアプリを登録（OIDC/OAuth のリダイレクト URI を設定）
az ad app create \
  --display-name "customer-portal" \
  --web-redirect-uris "https://app.example.com/auth/callback"

# 登録したアプリの appId を確認
az ad app list --display-name "customer-portal" --query "[].appId" -o tsv

# B2B コラボレーション: 取引先ユーザーをゲストとして招待
az ad user invite \
  --invited-user-email-address "partner@contoso.com" \
  --invite-redirect-url "https://app.example.com"

# 招待済みゲストを確認（userType が Guest になる）
az ad user list --query "[?userType=='Guest'].{name:displayName, mail:mail}" -o table