本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure AD B2Cカスタムポリシーによる高度な認証フロー
Azure Active Directory B2C（以下、Azure AD B2C）は、顧客向けのID管理サービスであり、その柔軟性を最大限に引き出すのがカスタムポリシーです。標準のユーザーフローでは実現が難しい、複雑な認証ロジック、外部システム連携、ブランドカスタマイズなどをカスタムポリシーによって実現できます。本稿では、クラウドアーキテクトの視点から、カスタムポリシーを用いた高度な認証フローの設計、実装、運用、セキュリティ、コスト、そして一般的な落とし穴について解説します。
アーキテクチャ
Azure AD B2Cのカスタムポリシーは、Identity Experience Framework（IEF）を基盤としており、XML形式の設定ファイル群で動作を定義します。これにより、開発者は認証・認可プロセスを細かく制御できます。
主要コンポーネント:
Relying Party (RP) アプリケーション: 認証をAzure AD B2Cに委任するアプリケーション（Web、モバイルなど）。
TrustFrameworkPolicy (カスタムポリシー): XMLファイルで構成されるポリシーセット。
Base Policy: グローバル設定、クレーム定義、クレームプロバイダー定義など、共通設定を記述。
Extension Policy: Base Policyを拡張し、新しい技術プロファイルやクレームプロバイダーを追加。
Relying Party Policy: アプリケーションが直接呼び出すポリシー。ユーザー体験（User Journey）と出力クレームを定義。
クレーム（Claims）: ユーザーの属性情報（例：メールアドレス、名、姓など）。
クレームプロバイダー（Claims Providers）: IDプロバイダー（ローカルアカウント、ソーシャルIDなど）またはカスタムロジック（REST API呼び出しなど）。
技術プロファイル（Technical Profiles）: 特定のプロトコル（OAuth2、OpenID Connect、REST APIなど）を使用してクレームプロバイダーと通信する方法を定義。
ユーザー体験（User Journey）: 認証フローの各ステップ（例：サインアップ、サインイン、プロファイル編集）を順序立てて定義。オーケストレーションステップ（Orchestration Steps）と呼ばれる単位で構成されます。
高度な認証フローの例:
条件付き認証: 特定のユーザー属性やデバイス情報に基づいて、追加のMFA（多要素認証）を要求したり、アクセスを拒否したりする。
外部システム連携: 認証プロセス中に外部の詐欺検出サービス、CRM、データベースなどと連携し、ユーザー情報を検証・拡充する（Microsoft Learn 2024-07-25 JST）。
カスタムMFA: Azure AD B2C標準以外のMFAプロバイダーを統合。
Just-in-Time (JIT) プロビジョニング: 外部データベースからユーザー情報を取得し、B2Cディレクトリにプロビジョニング。
以下のフローチャートは、カスタムポリシーを用いた高度な認証フローの一例を示します。
flowchart TD
A["ユーザー"] -->|"認証リクエスト"| B("RPアプリケーション")
B -->|"認証要求 (ポリシー指定)"| C("Azure AD B2C")
C -->|"ポリシー評価 (RelyingParty.xml)"| D{"ユーザー体験開始"}
D -->|"クレデンシャル収集"| E["サインイン/サインアップ画面"]
E -->|"入力情報送信"| F("Azure AD B2C")
F -->|"オーケストレーションステップ1"| G["クレーム検証/変換"]
G -->|"オーケストレーションステップ2"| H{"外部API呼び出しの要否?"}
H -->|"Yes: 詐欺検出、データ検証など"| I["外部REST API"]
I -->|"結果応答"| F
H -->|"No"| F
F -->|"オーケストレーションステップ3"| J["MFA要求/実行"]
J -->|"MFA成功"| F
F -->|"オーケストレーションステップ4"| K["最終クレーム作成"]
K -->|"JWT発行"| L("RPアプリケーション")
L -->|"セッション確立"| A設定手順
カスタムポリシーの作成は、Microsoftが提供するスターターパックをベースに行うのが一般的です（GitHub Azure-Samples 2024-07-15 JST）。
スターターパックのダウンロード:
SocialAndLocalAccountsなど、目的に合ったスターターパックを選択し、XMLファイルをダウンロードします。テナント名の置換: ダウンロードしたXMLファイル内の
{yourtenant}.onmicrosoft.comを実際のAzure AD B2Cテナント名に置換します。ポリシーキーの作成: クレーム暗号化や署名に使用するポリシーキーをAzureポータルで作成します。
XMLファイルの編集:
クレームの定義:
<ClaimsSchema>セクションで必要なクレーム（例:extension_FraudScore）を定義します。技術プロファイルの追加: 外部REST APIとの連携には、
REST-ful technical profileを<ClaimsProviders>セクションに追加します。 “`xmlREST API Call Fraud Check Service - https://your-fraud-api.azurewebsites.net/api/fraudcheck
- None
- Body
