Microsoft Entra ID（旧 Azure AD）で OpenID Connect を使う際、「Dynamic Client Registration（動的クライアント登録 / DCR）は使えるのか？」は、マルチテナントSaaSやMCP連携の文脈で特に重要になります。本記事では“対応の有無”を根拠付きで整理し、現場で成立する代替設計まで具体的にまとめます。
結論：Microsoft Entra ID（旧 Azure AD）は OIDC の Dynamic Client Registration（DCR）をサポートしていない
結論から言うと、Microsoft Entra ID（旧 Azure AD）は OpenID Connect の Dynamic Client Registration（動的クライアント登録 / DCR）をネイティブにサポートしていません。
Microsoft Learn（Microsoft Q&A）でも「Azure AD does not support OpenID Connect Dynamic Client registration」と明確に回答されており、同スレッドの後続質問でも「現時点では機能がなく、ロードマップにも“今のところ”入っていない」とされています。
さらに、Microsoft の公式ドキュメント（App Service の MCP 認可ガイド）でも「多くのプロバイダーは DCR をサポートしておらず、Microsoft Entra ID もその一つ」と明記されています。
「将来的に対応予定はある？」に対する現実的な読み方
Microsoft Learn の Q&A（2025年8月の回答）では、DCR について「現時点で機能はなく、ロードマップにも今は入っていない」とされています。つまり、“近い将来に提供される”と断言できる根拠は見当たりません。
一方で、Microsoft のロードマップは変動し得るため、要件として DCR が外せない場合は、Microsoft が案内しているフィードバック窓口へ要望を出しつつ、実装面では代替案で設計を成立させるのが現実的です。
Dynamic Client Registration（DCR）とは何か：何が“動的”で、何が嬉しいのか
OpenID Connect の Dynamic Client Registration は、アプリ（Relying Party / Client）が IdP（OpenID Provider / Authorization Server）に対してプログラム的にクライアント登録を行い、client_id（必要に応じて client_secret 等）を取得できる仕組みです。
なぜこれが必要になるかというと、典型的には次のような要件があるからです。
- あなたのアプリ（SaaS）が、顧客ごとに異なる IdP（Keycloak / Ping / Okta 等）を“セルフサービスで”追加できるようにしたい
- 顧客の管理者が都度 IdP 管理画面でクライアント登録する運用を避けたい
- 大量のクライアント（または大量の組み合わせ）を前提にし、手動登録がスケールしない
DCR に登場する用語（ざっくり把握）
| 用語 | 役割（何をするもの？） | 実務で気にする点 |
|---|---|---|
| Client Registration Endpoint | クライアント登録を受け付けるエンドポイント | これが無い IdP では DCR が成立しない |
| Initial Access Token | 登録エンドポイント呼び出しに必要な初期トークン（任意） | 匿名登録を許さない運用が一般的（特に企業向け） |
| Client Metadata | redirect_uri / grant_types 等、登録したい設定情報 | redirect_uri の管理が最重要（セキュリティ） |
対応可否の見分け方：OIDC の「.well-known」を見る
IdP が OIDC DCR に対応しているかは、まず OIDC Discovery（/.well-known/openid-configuration） を確認するのが定石です。DCR 対応の IdP では、しばしば registration_endpoint がメタデータに載ります（実装方針は IdP ごとに異なります）。
Microsoft Entra ID の .well-known を見ると「registration_endpoint」が無い
Microsoft Entra ID の OIDC メタデータ（例：common テナント）には、token_endpoint や authorization_endpoint などは掲載されていますが、registration_endpoint は含まれていません。
以下は読みやすさのために抜粋したイメージです。
{
"authorization_endpoint": "https://login.microsoftonline.com/common/oauth2/v2.0/authorize",
"token_endpoint": "https://login.microsoftonline.com/common/oauth2/v2.0/token",
"jwks_uri": "https://login.microsoftonline.com/common/discovery/v2.0/keys",
...
// registration_endpoint は見当たらない
}なぜ Entra ID は DCR を提供していないのか（設計思想と運用の都合）
公式回答は「未対応」という事実に尽きますが、実務観点では次の事情が大きいと考えると理解しやすいです（これは設計上の背景説明であり、Microsoft が明文化した理由そのものではありません）。
- クライアント登録＝ディレクトリ資産の作成であり、企業テナントではガバナンス対象になりやすい
- redirect_uri の管理が崩れると、OAuth/OIDC 全体の安全性が下がる（登録を誰でもできる形は採りにくい）
- Entra では「アプリ登録（App registrations）」や「サービスプリンシパル」が管理プレーンの概念として確立しており、DCR のような“ランタイムの登録”を標準化していない
実際、Entra ID ではアプリ登録を誰が作れるかは重要な管理項目で、「既定ではユーザーがアプリ登録できるが、制限できる」とドキュメントにも記載されています。つまり、“クライアント登録は管理の領域”という色が濃いです。
よくある要件：アプリ上から IdP を追加できるようにしたい（BYO IdP / マルチIdP）
質問にあるユースケースは、ざっくり言うと以下のどれかに分類できます。
| 分類 | 例 | IdP 側で必要になるもの |
|---|---|---|
| 顧客ごとに IdP が違う | 顧客Aは Entra、顧客Bは Keycloak、顧客Cは Ping | 原則として“顧客ごと”に client_id/secret と redirect_uri の登録が必要 |
| 同一顧客内で複数 IdP を許可 | 同一テナントで複数のSSO方式を併用 | 構成管理が複雑化（運用設計が勝負） |
| エコシステム連携で DCR が期待される | MCP など「クライアントの組み合わせが爆発する」世界 | DCR があれば楽だが、Entra では静的 client_id 前提になりがち |
代替案の全体像：Entra ID 前提なら「DCR なしで成立するオンボーディング」に寄せる
Entra ID に “標準DCRエンドポイントが無い” 前提では、設計として現実的な落としどころは大きく3つです。
| 代替案 | 一言で | 向いているケース | 注意点 |
|---|---|---|---|
| 事前登録（手動） | 顧客管理者が Entra 管理画面でアプリ登録 | 顧客数が少〜中、ガバナンス重視 | オンボーディングのUXが重要（手順が長いと離脱する） |
| Graph で登録自動化（擬似DCR） | あなたの仕組みが Graph API で “アプリ登録を作る” | 顧客数が多い、手動が耐えない | 管理者同意・権限設計・監査が必須 |
| DCR 対応 IdP を別に用意 | 要件を満たす IdP へ寄せる / ブローカーを挟む | DCR が仕様上どうしても必須 | 構成が増える（運用/コスト/責任分界が変わる） |
代替案 1：事前登録（手動）を“プロダクトの機能”として設計する
「顧客管理者が Entra ID 側でアプリ登録 → client_id/secret をあなたのアプリに入力」という形は、Entra 環境では最も王道です。ポイントは、手動作業を“運用”で片付けず、オンボーディング体験として設計することです。
手動オンボーディングで最低限そろえる情報
| あなたのアプリが提示するもの | 顧客が Entra で設定するもの | 顧客があなたのアプリへ入力するもの |
|---|---|---|
| リダイレクトURI（例：本番/検証） | Redirect URI（Web/SPA/ネイティブに合わせる） | Client ID |
| 必要スコープ（例：openid profile email offline_access など） | API Permissions / スコープ | Client Secret または証明書 |
| ログアウト後遷移先（必要なら） | Front-channel logout / Redirect URI（必要に応じて） | Tenant ID（またはドメイン） |
“入力ミス”を減らすための UX アイデア（実務で効く）
- コピー＆ペースト前提の値を、あなたの管理画面で明確に提示する（Redirect URI、必要スコープ、許可されたアカウント種別など）
- 入力後に、あなたのアプリ側で OIDC メタデータを取得して疎通チェック（issuer / jwks_uri / token_endpoint を検証）
- Tenant ID の指定ミスを防ぐため、サインイン後の id_token の iss / tid で整合性を自動判定してアラート表示
代替案 2：Microsoft Graph でアプリ登録を自動化する（標準DCRではないが“体験”は近づけられる）
Entra ID に DCR エンドポイントが無くても、Microsoft Graph を使えばアプリ登録（Application オブジェクト）をプログラムで作成できます。これにより、あなたのサービス内に「IdP 登録ボタン」を用意し、裏側で自動登録する“擬似DCR”的な体験を実現できます。
Graph 自動化が成立する前提
- 顧客テナントに対して、あなたの自動化コンポーネントが Graph API を呼べること（認可が必要）
- アプリ登録を作成・変更できる権限（例：Application.ReadWrite.All など）を、顧客側の管理者が許可すること
- 監査・ガバナンス（誰がいつ作ったか、何を作ったか）を顧客が受け入れられること
ここが “標準DCR” と決定的に違う点で、Graph による自動化は管理プレーン操作です。匿名のクライアントが勝手に登録できる世界とは、思想が別物です。
Graph でやること（代表例）
| やりたいこと | Graph の代表的な操作 | 補足 |
|---|---|---|
| アプリ登録（Application）を作る | POST /applications | displayName は必須 |
| クライアントシークレットを発行する | POST /applications/{id}/addPassword | シークレットは応答で一度だけ返る運用が多い |
| サービスプリンシパル（Enterprise Application）を作る | POST /servicePrincipals | アプリ登録と別物なので注意 |
| 必要な API 権限を要求する | requiredResourceAccess を更新 | “要求”と“管理者同意”は別工程 |
Graph 自動化を“安全に”運用するためのチェックリスト
- 最小権限：本当に必要な Graph 権限だけを要求する（過剰権限は導入拒否されやすい）
- 作成したアプリの所有者：顧客側の管理者/運用アカウントを owner に設定し、あなたが永続的に握り続けない
- 秘密情報の取り扱い：client_secret をあなたのDBに保存する場合、暗号化・アクセス制御・ローテーション計画を用意
- 監査ログ対応：どのタイミングでどのオブジェクトを作ったかを、顧客が追える形にする（運用説明が必須）
- テナント設定差：顧客によって「アプリ登録を作れるユーザー/アプリ」が制限されている場合がある
代替案 3：DCR が仕様要件なら、IdP を分ける／ブローカーを挟む
もし DCR が「あると便利」ではなく“無いと仕様が成立しない”レベルで固定要件なら、選択肢はシンプルになります。
- DCR を提供する IdP（例：Keycloak など）に寄せる
- あなたのシステム側で IdP ブローカー（中継）を用意し、そこで DCR を実装する
- Entra は“ユーザー認証の上流”として利用しつつ、クライアント登録の受け皿は別コンポーネントにする
実際に、MCP の文脈でも「Entra そのままでは DCR を満たせないので、プロキシ的な仕組みで吸収する」という設計の話が出てきます。Entra を捨てずに要件を満たす“折衷案”としては有効ですが、責任分界とセキュリティ設計の難易度は上がります。
判断表：あなたの要件ならどれを選ぶべきか
| 優先事項 | おすすめ | 理由 |
|---|---|---|
| ガバナンス最優先（顧客の統制が強い） | 事前登録（手動） | 管理者が意図して登録し、監査も分かりやすい |
| 顧客数が多く、手動オンボードが破綻する | Graph 自動化（擬似DCR） | オンボードの工数を削減できる。ただし権限と監査が必須 |
| “誰でも任意の組み合わせ”が前提（登録が爆発する） | DCR 対応 IdP / ブローカー | 標準DCRが無いとスケールしない世界観 |
| Entra を使いたいが、UXも捨てたくない | 手動＋ウィザード強化 | 顧客の管理者操作は残るが、迷わない導線で離脱を減らせる |
「DCR が無い」前提で失敗しがちなポイント
redirect_uri を増やし過ぎる
DCR を想定している設計だと、環境や顧客ごとに redirect_uri を動的に増やしたくなります。しかし Entra のアプリ登録では、redirect_uri の管理はセキュリティに直結します。“登録が増え続ける” 仕組みはレビュー対象になりやすいため、可能ならパターンを固定して設計するのが安全です。
同意（consent）を見落とす
Entra の世界では、アプリが要求する権限に対してユーザーまたは管理者が同意する必要があります。MCP のガイドでも、クライアントが同意プロンプトを出せないケースでは「事前承認（preauthorization）」が必要になり得る、と説明されています。SSO の“最後の詰め”でハマりやすいので、早めに設計に織り込んでください。
「DCR＝勝手に登録できる」と誤解する
DCR の仕様上、匿名登録を許す実装もありますが、企業向け IdP では一般に難しいです。Entra が DCR を提供しない背景には、まさにこの “誰が登録できるか” のガバナンスが絡みます。Entra の運用では、アプリ登録権限を制御すること自体が重要テーマになっています。
すぐ使える実務テンプレ：Entra を IdP として登録させるときの「案内文」例
最後に、あなたのプロダクト内のオンボーディング画面に貼れる形で、案内文の粒度を例示します（文章はそのまま使うのではなく、あなたの実装に合わせて調整してください）。
- 登録方式：Microsoft Entra ID（旧 Azure AD）の「アプリ登録」でクライアントを作成します。
- 必要な値：Client ID、Tenant ID、Client Secret（または証明書）
- Redirect URI：（あなたのサービスが提示するURIをここに明記）
- スコープ：openid / profile / email（必要に応じて offline_access など）
- 確認：登録後、当画面で「接続テスト」を実行し、issuer / jwks / token エンドポイントの疎通を検証します。
まとめ：Entra ID で DCR は使えない。だからこそ「登録運用」を設計に組み込む
Microsoft Entra ID（旧 Azure AD）は、OIDC の Dynamic Client Registration（DCR）をサポートしていません。これは Q&A の公式回答、MCP 関連の Microsoft 公式ドキュメント、そして OIDC メタデータ上の事実（registration_endpoint が無い）からも確認できます。
一方で、要件を満たす方法はあります。Entra 前提なら、(1) 手動の事前登録を“プロダクト体験”として磨く、(2) Microsoft Graph で登録を自動化して擬似DCRに寄せる、(3) DCR 対応 IdP/ブローカーに責務を分離する、のいずれかが現実解です。あなたの顧客規模・ガバナンス要求・UX要件に合わせて、最初から「オンボーディングの設計」をプロジェクト範囲に入れて進めるのが成功の近道です。
コメント