Skip to main content
Dynamic Client Registration (DCR) を使用すると、クライアントアプリケーションは登録エンドポイントにAPIリクエストを送信して、自身を自動的に登録できます。DCRは高度に動的な一部のアーキテクチャでは柔軟性をもたらしますが、適切に保護しないと重大なセキュリティリスクにつながります。 本番環境にMCPを導入する場合は、DCRではなく手動CIMD登録を使用することをお勧めします。CIMDには、ドメイン検証済みのアイデンティティによる高いセキュリティ、シンプルな認証情報管理 (一度登録すれば、どこにでも導入可能) といった利点があり、オープンな登録エンドポイントに伴うリスクもありません。

​
前提条件

Auth0 で DCR を通じて作成されたアプリケーションはすべて、強化されたセキュリティ対策が適用されたサードパーティ製アプリケーションとなります。 デフォルトの権限、つまりすべてのサードパーティ製アプリケーションが利用できる API とスコープの基本セットを定義しておく必要があります。DCR では、アプリケーションごとに API アクセスを個別に構成できないため、この設定は必須です。 Auth0 Dashboard で、次の手順を実行します。
  1. Applications > APIs に移動し、対象の API を選択します。
  2. Settings タブを開きます。
  3. Default Permissions for Third-Party Applications までスクロールします。
  4. User-Delegated Access または Client Access で Authorized を選択します。
  5. 付与するスコープを選択し、保存 を選択します。

​
DCRを有効にする

デフォルトでは、DCRはすべてのテナントで無効になっています。DCRは、Auth0 Dashboardのテナント設定で有効にできます。
  1. ［ダッシュボード］>［設定］>［詳細設定］ に移動します。
  2. ［Dynamic Client Registration (DCR)］ トグルをオンにします。
  3. ［保存］ を選択します。

​
オープンなDCRエンドポイントの危険性

Auth0はオープンなDCRエンドポイントをサポートしています。そのため、追加の保護策を講じずにこの機能を有効にすると、インターネット上の誰もがテナント内にアプリケーションを作成できてしまいます。その結果、次のような脅威にさらされることになります。
  • リソースの枯渇：悪意のある攻撃者がスクリプトを実行して数百万件ものアプリケーションを登録し、テナントのアプリケーション上限を使い切らせることで、サービス拒否状態を引き起こすおそれがあります。
  • 不正アクセスの試み：攻撃者が独自のクライアントを登録し、システムの脆弱性を探ったり、不正アクセスを試みたりするおそれがあります。
  • テナントの設定ミス：審査を経ない自動登録によって安全でない設定のクライアントが作成され、セキュリティ体制に弱点が生じるおそれがあります。
  • 監督の欠如：厳格な監視を行わないと、誰がどのような目的でクライアントを登録しているのかを把握するのが難しくなります。

​
オープンなDCR エンドポイントの保護

Open Dynamic Client Registration (オープンなDCR) を使用すると、柔軟な MCP 統合が可能になります。ただし、認証を設けないままにしておくと、テナントが悪用されるおそれがあります。セキュリティ対策がなければ誰でもテナント内にアプリケーションを作成できるため、リソースの枯渇や不正アクセスの試み、テナントの誤設定などにつながる可能性があります。
これらのセキュリティオプションは、エンタープライズのお客様のみご利用いただけます。プランのアップグレードについては、Auth0の営業担当までお問い合わせください。
これらのリスクを軽減するには、次の2つの方法があります。 Auth0に組み込まれているテナントアクセス制御リスト (ACL) 機能を使用して、テナントのDCRエンドポイントにアクセスできるIPアドレス範囲やドメインを制限します。この方法では、カスタムドメインとAuth0の正規ホスト名 (例：tenant.auth0.com) の両方が保護されるため、包括的に防御できます。 正規のクライアントのIP範囲 (社内ネットワークや特定のクラウドプロバイダーなど) を把握しており、インフラストラクチャを別途管理することなくネットワークベースのアクセス制御を適用したい場合に最適な方法です。

​
リバースプロキシ

カスタムドメインの前段にリバースプロキシ (Cloudflare など) を配置すると、リクエストが DCR エンドポイントに到達する前にレート制限、フィルタリング、認証を行えます。これにより、リクエスト量の制御、独自の認証ロジックの実装、トラフィックパターンの監視が可能になります。 ただし、カスタムドメインにリバースプロキシを設定しても、DCR エンドポイントには Auth0 の正規ホスト名 (例：tenant.auth0.com) 経由で引き続きアクセスできるため、プロキシが迂回される可能性があります。包括的に保護するには、この方法をテナント ACL と併用してください。

​
多層防御

両方のアプローチを併用することで、多層防御によるセキュリティを実現できます。どちらのアプローチを選択する場合でも、テナントのログを定期的に監視し、不審な登録パターンを検知してください。
両方のアプローチを併用することで、多層防御によるセキュリティを実現できます。テナントのログを定期的に監視し、不審な登録パターンを検知してください。

​
DCRアクティビティの監視

テナントのログを定期的に確認し、アプリケーションが短時間に大量作成されていたり、想定外の送信元から登録されていたりといった不審なパターンがないかを把握してください。 クライアントの登録を監視するには、以下の手順に従います。
  1. Auth0 Dashboardで［Monitoring］>［ログ］に移動します。
  2. 次の検索クエリを使用します：type:sapi AND description:"Dynamic client registration" これにより、成功したManagement APIオペレーション (sapi) のうち、Dynamic Client Registrationイベントに関するものだけに絞り込まれます。
  3. ログエントリで次の点を確認します。
    • 異常な件数：短時間に複数のクライアントが作成されていないか
    • 想定外の送信元：見慣れないIPアドレスや場所からの登録がないか
    • 不審なパターン：類似したクライアント名、想定外のドメインを指すCallback URL、営業時間外に作成されたクライアントがないか

​
Auth0 CLIでログを取得する

Auth0 CLIを使用して、DCRのログをプログラムで取得することもできます。
DCRイベントをSIEMや監視プラットフォームに転送し、不審な登録アクティビティを自動でアラート通知できるように、ログストリームを設定することをお勧めします。

​
MCPサーバーの認証と認可

MCPサーバーをインターネットに公開する場合は、セキュリティを確保する必要があります。MCP仕様では、こうしたやり取りを保護する手段としてOAuth 2.1の使用を推奨しています。OAuth 2.1を使用すると、MCPサーバーは認証を専用の認可サーバーに委任できるほか、スコープを使ってクライアント、ユーザー、操作ごとにアクセス制御を管理できます。

​
必須のサーバー設定

クライアントがサーバーとやり取りできるようにするため、MCP仕様では、認可設定を公開し、標準のHTTPレスポンスを使用することが求められています。
  1. 401エラーにはWWW-Authenticateヘッダーを使用する クライアントが有効なトークンを持たずにリクエストを送信した場合、サーバーは401 Unauthorizedステータスを返す必要があります。特に重要なのは、このレスポンスに、上記で設定したメタデータURLを指すWWW-Authenticateヘッダーを含めることです。これにより、クライアントは認証が必要であることを把握し、認可メタデータをどこから取得すればよいかを正確に知ることができます。
  2. 保護リソースメタデータ (RFC 9728) で認可サーバーを公開する MCPサーバーは、どこで認可を受ければよいかをクライアントに伝える必要があります。そのためには、メタデータエンドポイントを公開しなければなりません。サーバー上に.well-known/oauth-protected-resourceエンドポイントを作成し、Auth0テナントを指すJSONオブジェクトを返すようにしてください。これにより、MCPクライアントは手動で設定しなくても、認可エンドポイントを自動的に検出できます。