Entra External ID（旧 Azure AD B2C の後継）で顧客向けアプリを構築すると、「同じ URL／アプリに社員もログインさせたいので、Workforce テナントをカスタム OIDC の IdP にしたい」という要件がよく出てきます。本記事では、2025 年時点の制約と、現実的に取り得るアーキテクチャを整理します。
シナリオの整理：External ID と Workforce テナントで同じアプリを共有したい
まず、この記事で想定している典型的なシナリオを整理します。
- 顧客向けポータル／SaaS アプリを Microsoft Entra External ID（外部テナント／CIAM） で公開
- 同じアプリに、自社の社員（Workforce テナント のユーザー）もログインさせたい
- 社員は既存の Entra ID（Workforce）アカウントや条件付きアクセスをそのまま使いたい
- アプリ側ではできれば 1 つの OpenID Connect 設定だけ で完結させたい
このとき多くのアーキテクトが最初に思いつくのが、
「External ID テナントのカスタム OIDC IdP として、自社 Workforce テナントを登録すれば良いのでは？」
という案です。結論から言うと、これは 現時点ではサポートされていません。
前提：External ID と Workforce テナントのおさらい
ドキュメント上では、Entra ID には大きく分けて次の 2 つのテナント構成があります。
| 種類 | 用途 | 代表的なユースケース |
|---|---|---|
| Workforce テナント | 社員・内部アプリ・Microsoft 365 等を管理 | 社内ユーザーの認証、B2B コラボレーション、Teams / SharePoint など |
| External テナント（External ID for customers） | 顧客・ビジネス顧客向けアプリの CIAM 専用 | Web / モバイルアプリのサインアップ・サインイン、顧客 ID 管理 |
External テナント（CIAM）では、次のようなサインイン手段が用意されています。
- メールアドレス＋パスワード
- メールワンタイムパスコード（OTP）
- Facebook / Google / Apple などのソーシャル ID
- カスタム OIDC IdP
- カスタム SAML / WS‑Fed IdP
一方、Workforce テナント側では主に以下のような外部 ID 機能があります。
- B2B コラボレーション：他テナントのユーザーをゲストとして招待
- B2B 直接接続（Teams 共有チャネルなど）
- クロステナント同期：相互のテナント間で B2B ユーザーを自動作成・更新
今回の論点
問題になっているのは、External テナント（CIAM 側）で 「カスタム OIDC IdP」 を追加するとき、Workforce テナントの OIDC エンドポイントを指定できるのか？ という点です。
結論：Workforce テナントは External ID のカスタム OIDC IdP にできない
2025 年 10 月時点の公式ドキュメントでは、External ID のカスタム OIDC 設定について次のように明記されています。
- 「他の Microsoft Entra テナントを外部 IdP として構成することはサポートされていない」
- その結果、
microsoftonline.comドメインを含む issuer URI は 受け付けられない
実際、External ID の管理センターや Microsoft Graph API からカスタム OIDC IdP を追加しようとして、issuer に https://login.microsoftonline.com/{テナントID}/v2.0 のような URL を指定すると、バリデーションエラーで拒否されます。
| IdP としての構成対象 | External ID のカスタム OIDC IdP として |
|---|---|
| 自社 Workforce テナント（Entra ID） | 不可（issuer が microsoftonline.com のため拒否） |
| Azure AD B2C テナント | 可（サポート対象として明示） |
| 他社の OIDC 対応クラウド IdP（Auth0, Okta 等） | 可（OIDC 規格に準拠していれば利用可能） |
個人 Microsoft アカウント（MSA、live.com） | 可（専用ドキュメントあり） |
さらに、Microsoft Q&A でも、まさに本記事のテーマと同じ質問（External ID から Workforce テナントにサインインしたい）に対して、Microsoft スタッフから次のような回答が出ています。
- Workforce テナントを External ID の Custom OIDC Identity Provider としてフェデレーションすることはできない
- UI と Graph API は
microsoftonline.comの issuer を サポート外として拒否する
つまり、2025 年時点では
「Workforce テナントを External ID のカスタム OIDC IdP として登録する」ことは仕様上できない
と理解しておくのが安全です。
なぜサポートされていないのか（推測を含む整理）
公式には「サポートされない」とだけ書かれており、明確な理由は公開されていません。ただし、周辺ドキュメントとアーキテクチャから、次のような事情が推測できます。
- Entra テナント同士の連携は B2B / クロステナントが基本
Workforce と他テナント（Workforce でも External でも）との連携は、B2B コラボレーションやクロステナント同期を前提とした設計になっており、OIDC IdP としてぶら下げるモデルとは思想が異なります。 - 認証ループ・セキュリティモデルの複雑化を避けたい
Entra → External ID → 別 Entra → … というようにテナント同士を相互に IdP 化すると、トークン発行元とリソーステナントの境界が曖昧になり、条件付きアクセスや監査ログの整合性が崩れやすくなります。 - サポート範囲を「非 Entra IdP」に限定する設計
OIDC IdP サポートの公式ブログでも、現時点の用途として Azure AD B2C や各種クラウド IdP、政府系 ID プロバイダーとの連携など「非 Entra テナント」を中心に説明しており、Entra ↔ Entra 連携は別ライン（B2B 等）でカバーする方針に見えます。
いずれにせよ、「やりたい気持ちは分かるが、現行のサポート境界から外れている」と捉えるのが良さそうです。
ロードマップ：対応予定は公開されているか？
2025 年末時点で、
- 公式ドキュメント（How-to、FAQ、Graph API リファレンスなど）
- Microsoft ID チームの公式ブログ
を確認しても、「Workforce テナントを External ID の OIDC IdP にできるようにする」ことを約束したロードマップは公開されていません。
コミュニティでの Q&A の中には、サポート窓口から「将来的に対応したい意向はあるが、日付は未定」といったニュアンスが共有されているケースもありますが、これはあくまで 非公式なコメント であり、設計判断の根拠にするにはリスクがあります。
したがって、設計時には
「当面はサポートされない前提」でアーキテクチャを組み、後からサポートされたら差し替えやすい構造にしておく
というスタンスが無難です。
要件の整理：「同じアプリに顧客と社員がアクセスしたい」
選択肢を比較しやすくするために、まず実現したい要件を分解してみます。
| 観点 | 顧客（External ID） | 社員（Workforce） |
|---|---|---|
| サインイン元 | External テナント or ソーシャル ID / OIDC / SAML | Workforce テナント（会社アカウント） |
| ポリシー | シンプルな MFA / リスクベース、国別制御など | 厳格な条件付きアクセス、デバイス準拠など |
| アプリの URL | 可能であれば 同じ URL / ドメイン を使いたい | |
| アプリ実装 | トークン検証や RBAC を できるだけ共通化 したい | |
ここから導かれる重要なポイントは次の 2 つです。
- 顧客と社員で認証プラットフォームは分けたい（External / Workforce）
- しかしアプリ側から見ると1 つのサービスとして扱いたい
このギャップを埋めるために、次のような構成パターンが現実的な選択肢になります。
現実的なアーキテクチャパターンの全体像
| パターン | 概要 | 特徴 |
|---|---|---|
| A. External ID に一本化＋社員は B2B ゲスト | 社員を External テナントにゲストとして招待し、同じ External テナント発行のトークンでアプリを利用 | アプリは 単一の issuer を検証すればよい。構成がシンプル |
| B. アプリ／API 側で二つの issuer を受け入れる | External ID と Workforce の 両方から直接サインイン させ、バックエンドでどちらのトークンも検証 | それぞれのテナントのポリシーをそのまま活用できるが、アプリ実装はやや複雑 |
| C. SAML / WS‑Fed で External ID と社内 IdP を連携 | AD FS 等の SAML / WS‑Fed IdP を介して、社員を External ID 側へフェデレーション | レガシー要件や既存 SAML 基盤との互換が必要な場合に有効だが、運用コストが高い |
それぞれのパターンをもう少し深掘りしていきます。
パターン A：External ID に一本化し、社員は B2B ゲストとして扱う
最も素直で構成がシンプルなのが、この 「External テナント中心」アーキテクチャ です。
構成イメージ
- External テナント：顧客アカウント ＋ 社員ゲストアカウント ＋ 顧客向けアプリ登録
- Workforce テナント：社員のホームテナント（元の会社アカウントを保持）
- 社員は、Workforce の資格情報でサインインしつつ、External テナント側には B2B ゲスト として存在
Entra External ID の B2B コラボレーション機能では、他テナントのユーザーを招待してゲストユーザーオブジェクトとしてディレクトリに追加できます。
設定の流れ（概要）
- External テナントで顧客向けアプリを登録し、ユーザーフロー（サインアップ／サインイン）を構成
- External テナント側で Workforce テナントとのクロステナントアクセス を許可（B2B コラボレーション設定）
- External テナントに、社員の UPN（
@contoso.com等）を使ってゲスト招待を実施 - 社員が招待メールを受け取り、自分の会社アカウントで同意してゲストとして参加
- External テナントで、ゲストユーザーをグループやロールに割り当て、アプリへのアクセス権を付与
ゲストユーザーは External テナントに UserType = Guest なユーザーオブジェクトとして保存されますが、認証自体は自分のホームテナント（Workforce）側で行われます。
クロステナント同期でライフサイクルを自動化
社員ゲストを手で招待しているとスケールしないので、クロステナント同期（cross-tenant synchronization） を使うと運用がかなり楽になります。
- Workforce テナントを「ソース」、External テナントを「ターゲット」として同期設定
- 特定のグループに属する社員だけを External テナントに自動同期
- 異動・退職時には、Workforce 側の属性変更に応じてゲストも自動更新・削除
こうして作られたゲストユーザーは、手動招待と同様にアプリへアクセスできますが、ユーザープロビジョニングが完全に自動化されます。
パターン A のメリット
- アプリは External テナントの issuer だけを検証すればよい
→ バックエンドのトークン検証ロジックがシンプルになります。 - 顧客と社員を同じ RBAC モデルで扱いやすい
顧客ユーザーと社員ゲストを同じアプリロールやグループで権限管理できます。 - External ID の CIAM 機能をフル活用
ユーザーフロー、カスタム属性、ブランド、MFA ポリシーなどを External テナント側に集約できます。
パターン A のデメリット・注意点
- 社員の認証ポリシーを External テナント側で持つことになる
B2B ゲストとしてのアクセスには、External テナント側の条件付きアクセスや MFA が適用されます。Workforce テナントの CA ポリシーと組み合わせる設計が必要です。 - MAU 課金の考慮
External ID は「月間アクティブユーザー（MAU）」ベースの課金モデルであり、External テナントの認証アクティビティが MAU としてカウントされます。B2B ゲストや External テナントのユーザーは、無料枠（通常 50,000 MAU）を超えると課金対象です。 - 一部の社内システムが External テナントと連携しにくい可能性
既存の SaaS やオンプレアプリが「Workforce テナントのみ」を前提に SSO 構成されている場合、そのままでは External テナントのゲストを認識できないケースがあります。
とはいえ、「顧客向けアプリ」を中心に考えるなら、このパターン A が最も 設計・運用コストとシンプルさのバランスが良い ケースが多く見られます。
パターン B：アプリ／API 側で二つの issuer を受け入れる（デュアル・イシューア）
次に、External ID と Workforce の両方から 直接サインイン してもらい、バックエンドで二種類のトークンを受け入れるパターンです。
構成イメージ
- External テナントにアプリ登録（顧客向け）
- Workforce テナントにも同じアプリ（別クライアント）を登録（社員向け）
- フロントエンドで「顧客としてログイン」「社員としてログイン」という 2 つのボタンを表示
- それぞれが自分のテナント（External or Workforce）の OIDC エンドポイントにリダイレクト
- バックエンド API は、2 種類の issuer を認めるようトークン検証ロジックを実装
Microsoft のアーキテクチャガイドでも、Workforce と External を組み合わせた複数パターンが紹介されており、この「複数の IdP／テナントからのトークンを受け入れる」モデルは実務でもよく見かけます。
API 側の実装イメージ
- 受け入れる
issuerのリストにhttps://login.microsoftonline.com/{external-tenant-id}/v2.0https://login.microsoftonline.com/{workforce-tenant-id}/v2.0
- どの issuer から来たトークンかを見て
- クレームのマッピング（
oid/sub/email等）を標準化 - 「社員」「顧客」「パートナー」などのロールを付与
- クレームのマッピング（
言語・フレームワークによっては、ミドルウェア側で複数 Authority のサポートが薄い場合もあるため、その場合は API ゲートウェイやリバースプロキシ、あるいは IdP プロキシ製品 を前段に立ててトークン検証を一元化するのも手です。
パターン B のメリット
- Workforce テナントの条件付きアクセスをフル活用できる
社員は自分のホームテナントに直接サインインするので、既存の MFA、デバイス準拠、ロケーション制御などをそのまま利用できます。 - External と Workforce のポリシーを完全に分離
顧客は External テナントのポリシー、社員は Workforce テナントのポリシー、というように役割に応じたセキュリティレベルを設計可能です。 - 将来 OIDC での相互フェデレーションがサポートされた場合にも移行しやすい
もともと両テナントを直接使っているため、新機能が出ても構成変更が少なくて済みます。
パターン B のデメリット・注意点
- アプリ側の実装が複雑
issuer ごとにクレーム構造やロールの表現が異なる可能性があり、それを標準化するレイヤーが必要です。 - フロントエンドの UX 設計
「顧客なのに誤って社員ログインを選んでしまう」などの混乱を避けるため、ボタンの文言や説明、ドメインベースの自動判別（メールアドレスから社員を判定する等）を工夫する必要があります。 - 監査ログがテナントに分散する
顧客のサインインは External テナント、社員のサインインは Workforce テナントにログが出るため、監査やセキュリティ運用では両方のログを統合して見る仕組みが必要です。
パターン C：SAML／WS‑Fed で External ID と社内 IdP を連携
三つ目は、SAML / WS‑Fed を介したフェデレーション を使うパターンです。External ID は、SAML または WS‑Fed を話す IdP をカスタム IdP としてサポートしています。
構成イメージ
- 社内に AD FS や別の SAML IdP（例：On-prem IdP、サードパーティ IdP）が存在
- 社員はその IdP でサインイン
- External テナントからは、その SAML IdP に対してフェデレーションを設定
- External ID のサインイン画面に「社内アカウントでログイン」ボタンを追加し、SAML IdP 経由で認証
このモデルでは、社員のホームは Workforce テナントではなく SAML IdP 側 という扱いになります。そのため「Workforce を SAML IdP として直接ぶら下げる」というよりは、
Workforce ⇔ SAML IdP ⇔ External ID
という間接構成になるケースが多いイメージです。
パターン C がハマるケース
- 既に AD FS ベースの SAML 基盤があり、ここに External ID もぶら下げたい
- 一部の顧客やパートナーが SAML / WS‑Fed のみをサポートしている
- 規制要件や既存の統合基盤の都合で、SAML が必須となっている
パターン C のデメリット・注意点
- SAML / WS‑Fed はレガシー寄りの技術
新規構成では Microsoft 自身も OIDC / OAuth2 を推奨しており、SAML / WS‑Fed は「やむを得ない場合の選択肢」と考えた方が良いでしょう。 - 証明書／メタデータ更新の運用コスト
SAML メタデータの期限切れ、証明書ローテーション、クレーム名の不整合など、トラブルシュートの難易度が高めです。 - Workforce テナントとの関係性が複雑になりがち
AD FS や別 IdP と Workforce テナントの関係（パススルー認証か、フェデレーションか等）を含めると、全体像の理解とドキュメント化に手間がかかります。
したがって、パターン C は 「すでに SAML / WS‑Fed 基盤が存在し、それを External ID にも流用したい」 といった限定的なケースに向いています。
3 パターンの比較表
| 項目 | A：External ID に一本化＋B2B ゲスト | B：二つの issuer を受け入れる | C：SAML / WS‑Fed フェデレーション |
|---|---|---|---|
| アプリ側の実装難易度 | 低（単一 issuer） | 中〜高（複数 issuer） | 中（SAML 連携の知識が必要） |
| 社員の CA / デバイス準拠活用 | External テナント側が主。Workforce 側は B2B として連携 | Workforce テナントの CA をフル活用可能 | IdP 側の CA 次第 |
| ログ・監査の分散度合い | External テナントに集約しやすい | External / Workforce 両方に分散 | External ＋ SAML IdP ＋（場合により）Workforce |
| 運用コスト | 中（クロステナント同期や権限管理の自動化が鍵） | 中〜高（マルチ IdP 管理・監査） | 高（証明書更新、SAML トラブル対応） |
| 向いているケース | 顧客中心の SaaS / ポータル、シンプルな構成を優先 | 社員のセキュリティポリシーを最重要視、既に Workload 側で CA を作り込んでいる | レガシー SAML 環境や規制対応が必須 |
実装時に押さえておきたいチェックポイント
どのパターンを選ぶにしても、次のポイントを事前に整理しておくと設計がスムーズになります。
1. ポリシーの分離と優先度
- 顧客（External）と社員（Workforce）で求められるセキュリティレベルは違う
- 「顧客にはサインインしやすさ優先」「社員にはゼロトラスト前提の厳格な CA」など、ポリシーの差 を明文化しておく
- どのテナントのどのポリシーが最終的な Gatekeeper になるのかを図に落とす
2. ID 連携と「同一人物」の扱い
- 同じ人が「顧客アカウント」と「社員アカウント」を持つことがあります
- その場合、
- アプリ側でアカウントを統合（リンク）するのか
- あえて別人格として扱うのか
- メールアドレスや外部キー（CRM の Contact ID など）で突き合わせる設計もよく使われます。
3. コスト／ライセンスモデル
- External ID は MAU 課金（＋一部アドオン）であり、
- External テナントの顧客アカウント
- External テナントに存在する B2B ゲスト（社員ゲストを含む）
- Workforce テナント側では、P1 / P2 ライセンスや ID Governance アドオンなど、社員向けのライセンスモデルが別途存在します。
- 「顧客：社員 = 何：何」くらいのボリューム感を見積もっておき、どこにコストを寄せるかを検討しましょう。
4. ログ・監査・アラート設計
- issuer（発行者）ごとに、
- どのログにどんなイベントが記録されるか
- SIEM / Log Analytics への取り込み方法
- アラートの閾値・検知ロジック
- パターン B のように複数テナントからのサインインログを扱う場合、テナント ID・issuer・クライアント ID をキーに統合ビューを作っておくと運用しやすくなります。
5. 自動化：プロビジョニングと権限付与
- パターン A の場合：クロステナント同期や Entitlement Management を利用して、
- 社員の入社・異動・退社に応じたゲストの作成／更新／削除
- アプリロールやグループへの割り当て
- パターン B / C の場合：プロビジョニングはそれぞれのテナント／IdP 側で完結しやすいものの、アプリ側のロール割り当てや CRM 連携などはやはり自動化の仕組みを用意しておくと運用コストを抑えられます。
どのパターンを選ぶべきか？簡易な意思決定フロー
最後に、よくある条件別にざっくりとした指針を示します。
- 最優先は「顧客体験」と「実装のシンプルさ」
- → パターン A（External ID 一本化＋社員は B2B ゲスト）をまず検討
- 社員の条件付きアクセスやデバイス準拠を最大限尊重したい
- → パターン B（二つの issuer）で、社員は Workforce に直接サインインさせる
- 既に SAML / WS‑Fed 基盤があり、そこから移行したくない・できない
- → パターン C（SAML / WS‑Fed）を検討しつつ、中長期的には OIDC への移行ロードマップも描く
この記事のまとめ
- Workforce テナントは、2025 年時点では Entra External ID の「カスタム OIDC IdP」として登録できません。
Microsoft の公式ドキュメントと Graph API の仕様で、microsoftonline.comドメインを含む issuer URI は明示的に拒否されています。 - この制約を直接解消するロードマップは公開されていません。 将来のアップデートで変更される可能性はありますが、設計時点では「できない前提」で構成を組むべきです。
- 現実的な選択肢は大きく 3 つ：
- A：External ID に一本化し、社員は B2B ゲストとして招待・同期する
- B：アプリ／API で External と Workforce の 二つの issuer を受け入れる設計にする
- C：SAML / WS‑Fed IdP を介して社員を External ID にフェデレーションする（要件限定）
- どのパターンでも、ポリシー分離・ID 連携・コスト・ログ・自動化の 5 点を事前に整理しておくことで、後からの拡張や仕様変更に耐えられるアーキテクチャになります。
ひとことで言うと、
「Workforce テナントを External ID の OIDC IdP に直接ぶら下げることはできないので、B2B ゲスト／二重 issuer／SAML フェデレーションのいずれかで『社員も同じアプリに入れる』構成を選びましょう」
というのが、2025 年時点での現実解です。
コメント