Azure AD B2C のカスタムポリシーで外部パスキー IdP を直接呼び出していたアプリを、Microsoft Entra External ID に移行しようとすると、「ネイティブ認証では同じことができない」という壁にぶつかりがちです。本記事では、Entra External ID の最新仕様を整理しつつ、外部パスキー IdP をどう扱えるのか、そして現実的な代替案や移行パターンを具体的に解説します。
背景整理：B2C ではできたのに Entra External ID ではできない？
まずは、現在の前提条件を整理します。
- Azure AD B2C では、Identity Experience Framework (IEF) のカスタムポリシーを使うことで、
- REST API 技術プロファイルで外部システムを呼び出す
- 外部 IdP が提供するパスキー / FIDO2 API をアプリ側から直接叩き、その結果をカスタムポリシーに渡す
- ブラウザー リダイレクト無しで「ネイティブな」サインイン体験を作り込む
- 一方、Microsoft Entra External ID では、次のような新しい選択肢が用意されています。
- Microsoft ホストの「ブラウザー委任（リダイレクト）」によるユーザーフロー
- アプリ側 UI をフルカスタムできる「ネイティブ認証」
- ネイティブ認証では、ローカルアカウント IdP による
- メール + パスワード
- メール + ワンタイムパスコード（Email OTP）
結果として、多くのチームが直面するのが次の疑問です。
- 「B2C のように、リダイレクトなしで外部パスキー IdP を信頼するネイティブ認証フローは作れないのか？」
- 「もし無理なら、どんな落としどころ・代替案が現実的なのか？」
以降では、この問いに対して Entra External ID の仕様とロードマップを踏まえつつ、技術的な観点から整理していきます。
Azure AD B2C と Entra External ID（ネイティブ認証）の立ち位置の違い
まずは、Azure AD B2C カスタムポリシーと Entra External ID ネイティブ認証の役割の違いを、ざっくり比較しておきます。
| 項目 | Azure AD B2C（IEF カスタムポリシー） | Entra External ID（ネイティブ認証） |
|---|---|---|
| UI レイヤー | 基本は Microsoft ホスト UI（ブラウザー）が軸。JavaScript/CSS カスタマイズは可能だが限界あり。 | モバイル / デスクトップ / SPA の UI をアプリ側でフル実装。完全な「アプリネイティブ UI」設計が可能。 |
| 一次認証要素 | ローカルアカウント（ID/パスワード）、ソーシャル IdP、企業 IdP、カスタム IdP などカスタムポリシー次第で柔軟に構成。 | ローカルアカウント IdP による「メール + パスワード」「メール + OTP」のみ。フェデレーション IdP や FIDO2/パスキーはネイティブ認証では利用不可。 |
| 外部 REST API 連携 | REST 技術プロファイルを任意のステップに挿入可能。外部 IdP の独自 API も自由に呼び出せる。 | サーバー側の カスタム認証拡張（Custom Authentication Extensions） による REST 呼び出しが可能。ただし呼び出しポイントや戻り値の扱いが厳密に制御される。 |
| 外部 IdP（OIDC/SAML） | リダイレクト ベースのフェデレーション。必要に応じて複数 IdP を組み合わせ可能。 | ユーザーフロー（ブラウザー委任）では OIDC/SAML/ソーシャル IdP を利用可能。ネイティブ認証ではフェデレーション IdP は非対応。 |
| パスキー / FIDO2 | 外部 IdP 側が FIDO2/パスキーをサポートしていれば、カスタム IdP として統合可能。 | External ID 自身は 2025 年時点で FIDO2/パスキーを External tenant の主要な認証方法として公開していない。パスキー IdP を使いたい場合は、フェデレーション IdP 側でパスキーを実装し、ブラウザー リダイレクトで利用する形になる。 |
この表から分かる通り、「ネイティブ認証」は UI 自由度を高める代わりに、一次認証要素として利用できる方式をかなり絞り込んでいるのが特徴です。
Entra External ID のネイティブ認証がサポートするもの・しないもの
Entra External ID のネイティブ認証は、External tenant（いわゆる CIAM 用テナント）向けに提供される新しい認証モデルです。
サポートされている認証方法（一次要素）
2025 年時点で、ネイティブ認証の一次要素としてサポートされているのは以下の 2 つだけです。
- メールアドレス + ワンタイムパスコード（Email OTP）
- メールアドレス + パスワード（Self-Service Password Reset 対応）
これらは「ローカルアカウント IdP」による認証であり、ネイティブ認証 API の challenge type として明示的に定義されています。
サポートされていない要素
逆に、ネイティブ認証では現時点で次のような要素は サポートされていません。
- ソーシャル IdP（Google / Facebook / Apple 等）
- 企業 IdP（外部 OIDC / SAML）
- FIDO2 / パスキー（WebAuthn）
- SMS ベースの認証（一次要素として）
- SSO（シングルサインオン）
これらを使いたい場合は、従来型のブラウザー委任（リダイレクト）によるユーザーフローを利用することになります。
カスタム認証拡張とカスタムクレームプロバイダー
一方で、External ID では「カスタム認証拡張（Custom Authentication Extensions）」という仕組みを使って、サインアップ／サインイン フローの特定ポイントで REST API を呼び出し、外部システムと連携することができます。
- OnAttributeCollectionStart / OnAttributeCollectionSubmit
- サインアップ時の属性入力画面の前後で実行される
- 入力値のバリデーションやブロック、値の補完などに利用
- OnTokenIssuanceStart
- ユーザーがすべての認証チャレンジを完了し、トークンが発行される直前に実行される
- 外部システムから取得した属性をトークンにクレームとして追加できる（カスタムクレームプロバイダー）
- OnOtpSend
- Email OTP の送信を外部メールプロバイダー経由で行うためのイベント
特に OnTokenIssuanceStart + カスタムクレームプロバイダーで、外部 REST API から情報を取得し、発行トークンにクレームとして反映させることができます。
ただしこれはあくまで 「すでに Entra External ID でユーザーが認証済みである」ことを前提に、トークンに情報を足すための仕組みです。外部パスキー IdP を一次認証要素の代わりに差し替える用途ではありません。
「外部パスキー IdP をネイティブ認証で信頼する」を分解して考える
「外部パスキー IdP をネイティブ認証で信頼したい」という要件は、もう少し粒度を落として考えると次の 2 パターンに分けられます。
パターン A：パスキー IdP を一次要素として使いたい
- ユーザーはメール + パスワード / OTP を使わず、外部パスキー IdP だけでサインインしたい
- アプリ内で OS ネイティブのパスキー UI（WebAuthn）を表示し、その結果（Assertion 等）を外部 IdP に渡す
- 外部 IdP がユーザーの認証を行い、その結果を Entra External ID に伝えてトークンを発行してほしい
パターン B：メール + OTP/パスワード ＋ パスキー IdP（追加検証）として使いたい
- 一次要素は Entra External ID のローカルアカウント（メール + OTP/パスワード）
- その後に外部パスキー IdP を呼び出し、実質的な 2 段階認証（MFA 相当）として利用したい
- パスキー認証に失敗したらトークンを発行したくない
どちらを実現したいかで、取りうる選択肢が大きく変わります。
結論：ネイティブ認証の一次要素として外部パスキー IdP を組み込む手段はない
まず結論から整理します。
- ネイティブ認証のチャレンジタイプ（challenge type）は、現時点で
- Email OTP
- Email + Password
- ネイティブ認証のフロー中で、アプリから Entra External ID に対して「このユーザーは外部パスキー IdP で認証済みなので、メール + OTP/パスワードなしでトークンを発行してほしい」と伝える API は提供されていません。
- カスタム認証拡張やカスタムクレームプロバイダーは、あくまで 認証後にクレームを追加したりサインアップ時の属性を検証するための仕組みであり、一次認証方式そのものを置き換えることはできません。
したがって、
「外部パスキー IdP を一次認証要素として、リダイレクト無しのネイティブ認証フローに組み込む」
という意味での「信頼」は、2025 年時点では公式な手段が存在しません。
では何ができるのか？現実的な代替案
一次要素としてのパスキー IdP 組み込みはできないものの、アーキテクチャ次第では「UX を大きく崩さずに安全に妥協する」ことは可能です。ここからは代表的な代替案を整理します。
代替策 1：ブラウザー リダイレクト方式で外部 IdP とフェデレーション
もっともストレートでサポートされている選択肢は、ブラウザー委任（リダイレクト）を受け入れ、外部パスキー IdP を OIDC / SAML IdP としてフェデレーションする方法です。
| 観点 | ネイティブ認証 | ブラウザー委任（外部 IdP フェデレーション） |
|---|---|---|
| サインイン UX | アプリ内のネイティブ UI で完結。画面遷移は最小。 | 一度ブラウザーに遷移し、外部 IdP にリダイレクト。サインイン後にアプリへ戻る。 |
| パスキー利用 | External ID のネイティブ認証ではパスキー非対応。 | 外部 IdP がパスキー対応であれば、そこで FIDO2/WebAuthn を利用可能。 |
| SSO | SSO 非対応。毎回サインインが前提。 | ブラウザー Cookie / セッションを活用した SSO が可能。 |
| 実装コスト | アプリ側で UI とネイティブ認証フローの実装が必要。 | Entra External ID のユーザーフロー設定と標準 OIDC/SAML 実装で比較的少ない工数。 |
| セキュリティ | 実装次第で変動。フィッシング対策や安全なセッション管理をアプリ側で担う必要あり。 | Microsoft によるホスト UI と標準プロトコルにより、攻撃面を限定しやすい。 |
UX を崩さないための工夫
「リダイレクトが嫌だ」という声が上がりやすいですが、次のような工夫で違和感をかなり軽減できます。
- カスタム URL ドメイン（例：
id.example.com）を設定し、
ブラウザーに遷移しても常に自社ドメインが表示されるようにする。 - 外部 IdP 側のサインイン画面も自社ブランドに合わせてカスタマイズする。
- モバイルアプリでは OS のシステムブラウザー / カスタムタブを利用し、アプリとの行き来をスムーズにする。
- 「サインイン中…」のローディング画面をアプリ側で用意し、遷移の違和感を減らす。
完全にリダイレクトを無くすことはできないものの、「ユーザーからすると一瞬フル画面でサインイン画面が開き、そのまま戻ってくる」程度まで UX を落とし込むことは十分に可能です。
代替策 2：Azure AD B2C を継続運用し、移行を段階的にする
もし「どうしてもリダイレクト無しの UX を維持したい」「外部パスキー IdP との統合コードを書き直す余裕がない」という場合は、Azure AD B2C の継続運用という選択肢もまだ現実的です。
Microsoft の公式 FAQ では、Azure AD B2C は少なくとも 2030 年まではサポートが継続されると明記されています（一部ライセンス SKU の終了は別途あり）。
| 観点 | B2C 継続運用のメリット | 注意点 |
|---|---|---|
| 既存実装 | カスタムポリシーや外部パスキー IdP 連携ロジックをそのまま維持できる。 | 長期的には External ID への移行が推奨されるため、どこかで作り直しが必要。 |
| 機能ギャップ | 現時点で B2C にしかないユースケース（高度なポリシー制御など）を維持可能。 | 新機能は External ID 側に優先的に追加される傾向がある。 |
| 運用コスト | 既存運用プロセスを変えずに済む。 | B2C と External ID の「二重運用」期間が長くなると、管理が複雑になりがち。 |
実務上は、次のようなハイブリッド構成がよく検討されます。
- B2C：既存アプリ + 外部パスキー IdP 連携が必須なアプリ
- Entra External ID：新規アプリ、もしくはメール + OTP/パスワード中心で問題ないアプリ
将来的に External ID 側の機能が追いついたタイミングで、本格的な移行を行う、というロードマップです。
代替策 3：カスタム認証拡張で「追加チェック」としてパスキー IdP を使う
一次要素の代替はできないものの、「追加検証」「ビジネスルール判定」として外部パスキー IdP を組み合わせるパターンは検討の余地があります。
想定パターン（概念図）
- ユーザーはネイティブ認証（メール + OTP / パスワード）でサインインする。
- トークン発行前の OnTokenIssuanceStart でカスタム認証拡張が呼び出される。
- カスタム認証拡張の REST API で、外部パスキー IdP の API をコールし、「このユーザーがパスキー登録済みか」「リスクが高いセッションではないか」などをチェックする。
- 結果に応じて
- 問題なければ追加クレーム（例：
passkey_verified=true）を付与してトークン発行 - 問題があればエラーを返し、サインイン自体をブロック
- 問題なければ追加クレーム（例：
このパターンのポイントは、
- ユーザーの「本人確認」自体はあくまで External ID（メール + OTP/パスワード）が担う
- 外部パスキー IdP は「追加のリスク判定」「パスキー登録状況の確認」として利用する
という役割分担にすることです。
限界と注意点
とはいえ、このアプローチには明確な限界があります。
- パスキーの実際の認証 UI（WebAuthn のプロンプト）はどこで出すのか？
- OnTokenIssuanceStart はサーバーサイドのイベントであり、ユーザーに直接 UI を出すことはできません。
- 「サインイン前にアプリ側でパスキーを実行し、その結果トークンをどこかに渡す」といった複雑な設計が必要になり、現実的ではありません。
- External ID のセキュリティモデル的にも、「外部パスキー IdP による認証をそのまま一次要素として扱う」ことは想定されていません。
そのため、この代替策はあくまで「パスキー IdP をリスク判定や属性取得に使う」程度に留めるのがおすすめです。一次要素や MFA 相当の責任を外部パスキー IdP に全面的に持たせたいのであれば、やはりブラウザー委任によるフェデレーション方式とした方が素直です。
代替策 4：UX 目線での割り切りと設計パターン
認証方式としてはブラウザー委任を受け入れつつ、UX レベルで「いかにネイティブっぽく見せるか」を考えるのも現実的な戦略です。
- アプリ起動時のサインインを極力減らし、トークンとセッションのライフタイム設計を見直す
- サインイン画面をモーダル風に見せる（WebView やカスタムタブの活用）
- 「外部 IdP ログイン中」のプレースホルダーをアプリ内に用意し、体感待ち時間を減らす
- エラー時のメッセージをアプリ側で一元管理し、Microsoft ホスト UI 由来のメッセージとの差を吸収する
技術的な実現可能性だけでなく、「ユーザーの違和感をどこまで減らせるか」を軸に設計を見直すことで、リダイレクトを完全になくさなくても十分な UX を達成できるケースは多くあります。
移行戦略を考えるためのチェックリスト
最後に、Azure AD B2C から Entra External ID への移行、あるいは B2C 継続とのハイブリッド構成を検討する際のチェックリストをまとめます。
| 問い | Yes の場合の示唆 |
|---|---|
| ユーザー体験として「絶対にリダイレクトを見せたくない」ほど厳格な要件か？ | 本当に「絶対」かをプロダクトオーナーと再確認。多少のリダイレクト許容で設計が大幅にシンプルになることを説明する。 |
| 外部パスキー IdP は「一次要素」か、「追加検証」か？ | 一次要素として扱いたいなら、ブラウザー委任 + フェデレーション構成が前提。ネイティブ認証への統合は現状不可。 |
| 既存のパスキー IdP 連携コードを大きく書き換える余裕があるか？ | 余裕がなければ B2C 継続運用期間を長めに取り、External ID の機能進化を待つ判断も検討。 |
| 今後数年で新規の顧客アプリを複数立ち上げる予定があるか？ | 新規アプリは External ID（ネイティブ認証 or ブラウザー委任）で設計し、既存アプリは B2C のまま、といった二段構え戦略が有効。 |
| 外部パスキー IdP 側が OIDC / SAML フェデレーションに対応しているか？ | 対応しているなら、ブラウザー委任ユーザーフローにそのまま組み込める可能性が高い。 |
| 現在のパスキー要件は「規制・コンプライアンス」由来か？ | 規制要件であれば、External ID における将来のパスキー対応ロードマップをマイクロソフト側と確認した上で、中長期計画を立てる。 |
将来ロードマップと Microsoft へのフィードバック
Entra External ID は 2024〜2025 年にかけて急速に機能拡張が続いており、ネイティブ認証やカスタム認証拡張もその一部として強化されています。
しかし、
- External tenant における FIDO2 / パスキーの一次要素対応
- 外部パスキー IdP のネイティブ認証フローへの直接組み込み
といった点については、少なくとも 2025 年時点で明確な公開タイムラインは示されていません。
こうしたニーズを製品側に届けるには、以下のようなアクションが有効です。
- Microsoft Feedback Portal で、「具体的なユースケース」と「B2C でできていたこと」を書いたフィードバックを投稿する
- アカウントチーム経由で、ロードマップとギャップについて直接議論する
- 同様の要件を持つ社内・業界内のチームと連携し、フィードバックの優先度を高める
特に「カスタムポリシーで外部パスキー IdP をネイティブ統合していた既存システムがあり、External ID 移行で同等の UX を維持できない」という具体的なストーリーは、ロードマップ検討において強い材料になります。
まとめ：今できることと、割り切るべきポイント
本記事のポイントをあらためて整理すると、次のようになります。
- ネイティブ認証は「メール + パスワード」「メール + OTP」のローカルアカウントのみを一次要素としてサポートし、外部 IdP（パスキー IdP 含む）を一次要素として組み込むことはできません。
- カスタム認証拡張やカスタムクレームプロバイダーを使えば、外部 REST API を呼び出し、トークンに追加クレームを載せることは可能ですが、一次認証方式を外部パスキー IdP に置き換える用途ではありません。
- 外部パスキー IdP をフルに活かしたい場合は、
- ブラウザー委任 + OIDC/SAML フェデレーション方式に UX 面の工夫を加える
- 当面は Azure AD B2C の継続運用・ハイブリッド構成を取り、External ID の進化を待つ
- どうしてもリダイレクトを嫌うと設計の自由度が著しく下がるため、「どこまでなら UX の妥協が許されるか」をプロダクト側と正面から議論することが重要です。
- 同時に、Microsoft Feedback Portal などを通じて「外部パスキー IdP をネイティブ認証に統合したい」という具体的な要望を届けることで、将来の機能拡張の可能性を高めることができます。
結論として、現時点では「外部パスキー IdP をリダイレクト無しのネイティブ認証フローに一次要素として組み込む公式な手段は存在しません。UX 要件を満たすためには、Azure AD B2C の継続利用、あるいはブラウザー委任方式への設計変更という割り切りが必要になります。そのうえで、カスタム認証拡張を用いた外部システム連携や UX 改善テクニックを組み合わせ、ユーザー体験と移行コストのバランスを取ることが現実的な落としどころと言えるでしょう。
コメント