社内で開発・運用していない既存アプリを、将来的に顧客向けサインインで Microsoft Entra External ID（旧 Azure AD B2B/B2C）とフェデレーションする――その可否を最短で見極めるための「技術要件チェックリスト」と実装の勘所を、セルフサインアップ／パスワードリセット／カスタムブランディングに焦点を当てて体系化しました。ベンダーへの依頼文・試験観点まで一気通貫で利用できます。
目次
背景とねらい
既存のSaaSやパッケージを顧客向けに展開する際、社外ユーザーのアイデンティティは自前で持たず、IdP（Identity Provider）に委譲するのが標準設計です。Microsoft Entra External ID は「顧客ID（旧 B2C）」と「外部コラボレーション（旧 B2B）」を包含する外部アイデンティティ基盤で、OIDC/SAML によるフェデレーション、MFA・条件付きアクセス、ブランディング、セルフサービスのサインアップ／パスワードリセットを提供します。本稿では、アプリ側で何ができれば統合が成立するのかを、実務で使える粒度でまとめます。
用語の整理（役割分担）
- IdP（Identity Provider）：Microsoft Entra External ID。外部ユーザーを認証し、トークン（ID/Access Token）を発行。
- SP / RP（Service Provider / Relying Party）：既存アプリ。IdPが発行したトークンを受け取り、検証・認可を行う。
以降のチェックは「既存アプリがRPとして適切にふるまえるか」を見る観点です。
まずはここから：統合の「最小要件」
以下の2点が満たされれば、セルフサインアップとパスワードリセットはEntra側の画面に完全委譲できます。
- OIDC（OpenID Connect）対応：Authorization Code フロー（PKCE対応を強く推奨）が使えること。
- リダイレクトURI／ポストログアウトURIを任意設定できること：環境ごと（本番・検証）に登録・切替が可能。
独自UIや属性マッピング、APIの保護、厳格なセッション制御などエンタープライズ要件がある場合は、この後の全チェックを満たすのが安全です。
要件チェックリスト（配布用）
| カテゴリ | 確認ポイント（アプリベンダーに記入してもらう項目） |
|---|---|
| 認証プロトコル | OAuth 2.0 / OpenID Connect に対応している（必須）。 SAML 2.0 も可だが、推奨は OAuth/OIDC。 Authorization Code + PKCE に対応（SPA/モバイルは必須）。 Discovery（/.well-known/openid-configuration）と JWKs の取得・ローテーションに対応。 |
| フェデレーション構成 | アプリを RP/SP として設定でき、外部 IdP（Entra External ID）のトークンを受領可能。 リダイレクトURI／ポストログアウトURIを環境単位で登録・切替可能。 メタデータの設定（OIDC Discovery または SAML Metadata）をインポート・更新可能。 ログアウトは RP-Initiated Logout（OIDC）または SAML SLO に対応。 |
| ユーザー種別の取り扱い | 社内ユーザーと外部ユーザーを区別できる（クレーム／テナントID／発行者で判別）。 マルチテナント利用可否、外部ユーザー数のライセンス上限や課金モデルの制約がない。 初回サインイン時の JIT（Just-In-Time）プロビジョニングに対応（ID基準でローカルユーザー自動作成）。 |
| セルフサービス サインアップ | Entra のセルフサインアップ・ユーザーフロー（またはカスタムポリシー）にリダイレクト可能。 メール確認等の検証に対応（email_verified 等のクレームを受領）。 サインアップ時に付与される氏名・会社名・部署・役割などのクレームを保存できる。 サインアップ後の同意（Consent）/規約同意の取得記録を自アプリ側にも保持可能。 |
| パスワード リセット | 外部ユーザーのパスワード管理をIdP側へ委譲（アプリは独自にパスワードを保持しない）。 「パスワードを忘れた」操作でIdPのリセットフローへ遷移し、完了後にアプリへリダイレクトできる。 アプリはパスワード再設定の結果をトークン検証のみで反映（再ログイン要求やセッション再確立）。 |
| カスタムブランディング | Entra のブランド化されたサインインページ（ロゴ／配色／背景）を利用可能。 またはリダイレクト方式で独自ホストのUIを利用（B2C相当のカスタムページテンプレート/コンテンツ定義）。 カスタムドメイン（例：login.example.com）の利用を想定したリダイレクトURI設定が可能。 |
| セキュリティと準拠 | MFA・条件付きアクセスをIdPで強制し、アプリはクレーム（例：amr）で結果を参照。 トークン検証：iss/aud/exp/nbf/nonce/state の検証と署名鍵のローテ対応。 リフレッシュトークンのローテーション／失効（再利用検知）に対応し、トークン失効時に強制再認証できる。 クレームベースのアクセス制御（アプリロール／スコープ／テナント／グループ／カスタム属性）を実装。 ブラウザのSameSite/Secure属性・CORSを適切に設定し、サードパーティCookie制限を考慮。 |
| API 保護（該当する場合） | 公開APIは Entra のアプリ登録とOAuth 2.0 スコープ／アプリロールで保護。 API側は 受信アクセストークンの検証（aud/scp or roles）を実装。 バックエンド間はクライアント資格情報フロー（機密クライアント）に対応。 |
| ログ/監査・運用 | フェデレーションエラー時の相関ID（trace-id 等）の記録。 サインイン・サインアップ・リセット・ログアウトの時刻・ユーザーID（sub）・acr/amrの追跡。 鍵更新・設定変更のローリングリリースやメンテナンス手順の整備。 |
セルフサインアップを成立させる実装論点
受領する主なクレームと保持例
| クレーム | 意味 | アプリ側の扱い |
|---|---|---|
sub | 永続一意ID（ユーザーの主キー） | ローカルユーザーと強固にひも付け（メール変更でも不変）。 |
iss | トークン発行者（Entra テナント/ポリシー） | 想定の発行者のみ許可。マルチテナント時はリスト管理。 |
aud | トークンの受信者（このアプリ） | アプリのクライアントIDと一致必須。 |
email/email_verified | メールアドレスと検証済みフラグ | 業務上メールをログイン名に使う場合も、subを主キーとする。 |
given_name/family_name/name | 表示名系 | 初回作成時に保存し、以后はトークン優先かローカル優先かポリシー化。 |
acr（または tfp） | 実行されたユーザーフロー/認証コンテキスト | サインアップ・サインイン・パスワードリセットを判別。 |
amr | 実施された認証要素（例：mfa） | 高リスク操作で amr を検査し再認証を要求。 |
JITプロビジョニングの基本ロジック（疑似コード）
// 1) OIDC コールバックで ID トークンを受領
const idToken = verifyAndDecode(jwt);
// 2) ユーザー検索（主キーは sub）
let user = db.findByExternalId(idToken.sub);
// 3) なければ作成（必要属性をマッピング）
if (!user) {
user = db.create({
externalId: idToken.sub,
email: idToken.email,
name: idToken.name,
company: idToken.company || claims['extension_company'],
createdBy: 'entra-external-id'
});
}
// 4) セッション発行（ロールはクレーム or ローカル付与）
session.issue({ userId: user.id, amr: idToken.amr, acr: idToken.acr }); ポイントはメールではなく sub を主キーにすること。メールは将来変更され得ます。
パスワードリセットをIdPへ委譲する設計
- アプリはパスワードを保持・更新しない（ゼロ知識）。
- サインイン画面の「パスワードを忘れた」リンクはEntra のリセット用フローへ遷移。
- リセット完了後は OIDC の通常フローで新トークンを受領してサインインを再確立。
- 長期セッション中のリセットは、トークン再検証で失効を検知し再認証を促す。
実装者は「ローカルのパスワード変更API」や「暗号ポリシー」を用意する必要がありません。すべてIdP側の標準機能でカバーできます。
カスタムブランディングの選択肢
Entra 標準のブランド化ページを利用
- ロゴ／配色／背景画像／利用規約リンク／プライバシーポリシーリンクの設定。
- アプリからはただリダイレクトするだけで、統一感のあるサインイン体験が得られる。
独自ホストのUI（拡張カスタマイズ）
- ユーザーフローのページテンプレート（B2C相当のコンテンツ定義）を独自HTMLでホスティング。
- 高度なガイド・コピー・追加属性入力（会社名・同意チェック）をリッチに実装。
どちらの方式でもアプリはトークン検証の契約を守るだけで済むため、保守コストが低減します。
プロトコル詳細チェック（OIDC前提）
| 項目 | 必須要件 | 備考 |
|---|---|---|
| フロー | Authorization Code（PKCE対応） | SPA/モバイルはPKCE必須。機密クライアントでも推奨。 |
| エンドポイント | Discoveryで authorization_endpoint/token_endpoint/jwks_uri 取得 | 手動設定より安全。鍵ローテ対応が容易。 |
| IDトークン検証 | iss/aud/exp/nbf/nonce の検証 | 署名アルゴリズムはRS系。kidのローテに追従。 |
| CSRF対策 | state の厳密な照合 | リプレイ防止・セッション固定化対策。 |
| スコープ | openid 必須、属性に応じて email/profile 等 | API呼出は api://<app-id> ベースのスコープを要求。 |
| ログアウト | RP-Initiated Logout と post_logout_redirect_uri | セッション・クッキー破棄とセットで実施。 |
| エラー処理 | OIDC規定の error/error_description に対応 | ユーザー向け文言は共通化し、再試行・他経路サインインを案内。 |
API保護の設計（バックエンド～バックエンドも含む）
- APIはベアラートークンを受け取り、
audがAPIのアプリID URIかを厳密に検証。 - 機能権限制御は スコープ（
scp）またはアプリロール（roles）で表現。 - サーバー間はクライアント資格情報フロー（機密クライアント）でアクセストークンを取得。
- アクセストークンは短命、リフレッシュトークンはローテーションし、不正検知時はサーバー側で全無効化。
運用・セキュリティのベストプラクティス
- 条件付きアクセスでMFAやIP制限、リスクベースのステップアップをIdPに集約。
- アプリはクレームベースの認可と最小権限で機能を段階付与。
- 鍵ローテの影響を最小化するためDiscoveryとJWKsのキャッシュ＋自動更新を実装。
- 監査ログ：相関ID・
sub・acr・amr・フロー区分を保存。PIIは最小化。 - ブラウザ対策：SameSite=None; Secure、CSP、XSS/CSRF対策を標準化。
ベンダーへの依頼文テンプレート（コピペ可）
件名：Microsoft Entra External ID 連携の技術要件チェックのお願い
貴社アプリを当社の外部アイデンティティ基盤（Microsoft Entra External ID）とフェデレーションするため、
下記のチェックリストへのご回答をお願いします（対応可／要改修／未対応 の三択、備考を自由記入）。
1. プロトコル：OIDC（Authorization Code + PKCE）対応、SAML 2.0 対応の有無
2. リダイレクトURI／ポストログアウトURIの環境別設定可否
3. Discovery（/.well-known/openid-configuration）とJWKsローテ対応
4. セルフサインアップのIdP委譲可否、email_verified等のクレーム受領・保存
5. パスワードリセットのIdP委譲可否（忘れた場合の遷移・完了後の復帰動作）
6. カスタムブランディング対応（標準ページ or 独自ホストUI）
7. セキュリティ：MFA/条件付きアクセス結果の反映、トークン検証、RTローテ
8. API保護：アクセストークンのaud/scp/roles検証、クライアント資格情報フロー
9. セッション/ログアウト：RP-Initiated Logout、SameSite/CORS対応
10. 運用：監査ログ（sub/acr/amr等）、障害時の相関ID提示、鍵ローテ手順
期日：YYYY/MM/DD
ご不明点は本メールにご返信ください。 15分でできるスモークテスト（受入試験のたたき台）
- テスト用テナントで OIDC クライアントを発行し、開発環境のリダイレクトURIを登録。
- アプリの OIDC 設定に Discovery URL とクライアントID/シークレット（またはPKCEのみ）を設定。
- サインアップフローに遷移し、メール確認を経て新規ユーザーでログイン。
- アプリのユーザー一覧に sub を主キーとしたレコードが作成されていることを確認。
- サインイン中に「パスワードを忘れた」を選び、リセット完了後に再ログインできることを確認。
- ログアウトすると IdP 側も含めセッション終了し、
post_logout_redirect_uriに戻ること。 - API を呼び出す画面がある場合、アクセストークンの
aud/scpを検査して403が正しく働くこと。
よくある落とし穴と回避策
- メールを主キーにしてしまう：将来の変更で参照が壊れる。
subを主キーに。 - ログアウトでIdPを無視：ローカルセッション破棄だけでは不完全。RP-Initiated Logout を実装。
- 鍵ローテ無対応：固定鍵ピン留めは事故の元。Discovery + JWKs の自動更新を。
- PKCE未対応のSPA：セキュリティリスク。必ずPKCEを有効化。
- 同意管理の不備：利用規約・プライバシーの同意記録をアプリ側でも保存し、監査可能に。
- 多環境でのURI差し替え忘れ：本番・検証・開発でURIを分離し、Infrastructure as Codeで管理。
「B2B」と「顧客ID（B2C相当）」の使い分けの目安
- B2B（外部コラボ）：取引先の従業員が自社テナントアカウントでアクセス。クロステナントのポリシー・MFAを活用。
- 顧客ID（External ID for customers）：消費者／企業顧客の個別アカウントをEntraで発行・管理し、セルフサインアップやパスワードリセットを提供。
既存アプリに社外の幅広い顧客を登録させたい場合は後者が適合しやすい一方、取引先の企業アカウントをそのまま使わせたいなら B2B が自然です。
導入コストとライセンスの考え方（概要）
- 顧客IDシナリオは一般に月間アクティブユーザー（MAU）課金のモデルで設計されます（詳細は契約に依存）。
- ピークに合わせてキャパシティを自前確保する必要はなく、IdPのスケールに委譲できます。
- ログ・監査・保存データのPII取り扱いは自社の法務・セキュリティ基準でレビューを。
サンプル：WordPress等の汎用OIDCプラグインで試す場合の目安設定
| 設定項目 | 値の例・ポイント |
|---|---|
| Discovery URL | Entra External ID の OIDC Discovery を指定。手動入力は避ける。 |
| Client Type | Confidential（サーバー）または Public（SPA）。SPAはPKCE必須。 |
| Scopes | openid email profile を基本に、必要なAPIスコープを追加。 |
| Mapping | sub→外部ID、email→通知先、name→表示名。roles/groupsで権限を付与する場合はロール連携を有効化。 |
| Logout | RP-Initiated Logout を有効化し、post_logout_redirect_uri を登録。 |
「この表だけ渡せばOK」版：最終チェックシート
| カテゴリ | チェック観点 | 対応状況（記入欄） |
|---|---|---|
| プロトコル | OIDC（Auth Code + PKCE）対応／SAML対応／Discovery+JWKs対応 | 対応可／要改修／未対応 |
| フェデレーション | リダイレクトURI・ポストログアウトURIの環境別設定、RP-Initiated Logout | 対応可／要改修／未対応 |
| ユーザー種別 | 社内/外部の区別、JITプロビジョニング、マルチテナント | 対応可／要改修／未対応 |
| セルフサインアップ | メール確認、属性受渡、同意の記録、フロー切替 | 対応可／要改修／未対応 |
| パスワードリセット | IdP委譲、完了後の復帰、長期セッションの扱い | 対応可／要改修／未対応 |
| ブランディング | 標準ブランド化 or 独自ホストUI、カスタムドメイン | 対応可／要改修／未対応 |
| セキュリティ | MFA/条件付きアクセスの反映、トークン検証、RTローテ、CORS/SameSite | 対応可／要改修／未対応 |
| API保護 | aud/scp/roles検証、クライアント資格情報フロー | 対応可／要改修／未対応 |
| 運用 | 監査ログ、相関ID、鍵ローテ手順、IaCで設定管理 | 対応可／要改修／未対応 |
補足：公式ドキュメントをどう読むか
- 「Entra External ID アプリ統合ガイド」：OIDC/SAMLでの統合手順とユーザーフロー設計の全体像を俯瞰。
- 「Azure App Service のアイデンティティ シナリオ集」：Web/SPAs/モバイル別の実装パターンを比較。
一枚もののチェックリストは公開されていないため、本記事の表をベースに自社要件で差分追記するのが実務的です。
まとめ
Entra External ID との統合可否は、OIDC対応とリダイレクトURIの柔軟性でまず8割が決まります。セルフサインアップとパスワードリセットはIdPへ完全委譲し、アプリ側はJITプロビジョニング＋クレームベース認可に注力しましょう。ブランディングは標準ページから始め、必要に応じて独自UIに拡張。最後に、本稿のチェックリストをベンダーへ配布し「対応可／要改修／未対応」を記入してもらえば、短時間で実現性と改修範囲が可視化され、導入計画が前へ進みます。
再掲：要件チェックリスト（原文）
| カテゴリ | 確認ポイント |
|---|---|
| 認証プロトコル | – OAuth 2.0 / OpenID Connect に対応しているか（必須） – SAML 2.0 による連携も許容されるが推奨は OAuth/OIDC |
| フェデレーション構成 | – アプリを サービスプロバイダー (SP) として設定でき、外部 IdP（Entra External ID）が発行するトークンを受け取れるか – リダイレクト URI や メタデータ エンドポイント をカスタマイズ可能か |
| ユーザー種別の取り扱い | – 社内ユーザーと外部ユーザーを区別できるか – マルチテナント利用や外部ユーザー数に対するライセンス制限がないか |
| セルフサービス サインアップ | – Entra の セルフサインアップポリシーと統合できるか – メール確認などの検証手段に対応しているか – サインアップ時に渡される クレーム（氏名・会社名など）を保存できるか |
| パスワード リセット | – パスワード管理を IdP 側に委譲し、外部ユーザーのリセットフローを Entra に任せられるか |
| カスタムブランディング | – Entra の カスタムサインインページ（ロゴ・配色など）をそのまま利用するか、またはリダイレクト方式で独自 UI を使うか |
| セキュリティと準拠 | – 多要素認証 (MFA) や 条件付きアクセス ポリシーを強制できるか – トークン有効期限・リフレッシュトークンを正しく処理できるか – クレームベースのアクセス制御を実装できるか |
| API 保護（該当する場合） | – アプリが公開する API を Entra の アプリ登録と OAuth 2.0 スコープで保護できるか |
追加補足
- SP vs. IdP の用語整理
Entra External ID が IdPとして外部ユーザーを認証し、既存アプリが SPとしてトークンを受信する役割分担である点を、アプリ担当者に明示しましょう。 - 公式ドキュメントの現状
Microsoft から「一枚もの」のチェックリストは未提供。代替として「Entra External ID アプリ統合ガイド」「Azure App Service のアイデンティティ シナリオ集」が実装の参考になります。 - 最小実装の目安
OIDC 対応とリダイレクト URI 可変であれば、セルフサインアップやパスワードリセットは Entra 側画面に完全委譲可能。エンタープライズ要件（独自UI・属性マッピング・API保護など）がある場合は、本稿の全項目を満たすことを推奨します。
このチェックリストをベンダーへ配布し、各項目に「対応可／要改修／未対応」を記入してもらうと、Entra External ID との統合可否を短時間で評価できます。
コメント