https://example-client.com/mcp-metadata.json) 。CIMDのURLはアプリケーションのClient IDとして機能し、ドメインの所有権を証明します。これにより、信頼できるアプリケーションのみをAuth0に登録できます。Auth0はこれらの設定の記録を保持しますが、正となる情報源は常にホストされているCIMDです。
Auth0は、CIMDの手動登録と動的登録をサポートしています。
- CIMDの手動登録：CIMDのURLからアプリケーションを手動でインポートします。Auth0がCIMDを取得して検証し、アプリケーションをCIMDクライアントとして登録します。メタデータの変更は、手動で更新することで同期されます。
- CIMDの動的登録：アプリケーションがAuth0にOAuthリクエストを送信する際に、ランタイムでCIMDのURLを使って自身を登録します。メタデータの変更は、認可リクエストに応じてオンデマンドで同期されます。
CIMDクライアントは、テナントのCreate Permissive Third-Party Clients by Default設定にかかわらず、常に
third_party_security_mode: "strict"で登録されます。CIMDクライアントでは許容モードを使用できません。厳格モードのサードパーティアプリケーションはルールをサポートしていないため、テナントに有効なルールがあると、CIMDクライアントのログインフローは失敗します。ルールを使用している場合は、CIMDクライアントを登録する前にアクションへ移行してください。CIMDクライアントは、登録後に手動と動的を切り替えることはできません。切り替えるには、クライアントを削除してから再登録してください。
主な利点
手動CIMD登録には、次のような利点があります。- MCPクライアントのCIMDへの登録は、デプロイメントごとに一度だけで済みます。そのデプロイメントのすべてのインスタンスで、同じ登録認証情報が使用されます。
- 登録には、漏洩のおそれがある共有の対称シークレットではなく、非対称暗号 (公開鍵/秘密鍵) が使用されます。
- アプリケーションの所有者は、CIMDでクライアントメタデータを直接管理できます。Auth0は登録時に、これらのプロパティを内部の設定に自動的に対応付けます。
- CIMDのURLは、監査ログ内で人が読める識別子として機能します。そのため、特定のMCPツールサーバーやホストからのリクエストの発信元を簡単に確認できます。
ユースケース
手動CIMD登録の一般的なユースケースは次のとおりです。- MCPクライアント：CIMDでの登録は、デプロイメントごとに一度行うだけで済みます。そのデプロイメントのすべてのインスタンスで同じ登録認証情報を使用します。Auth0によるMCPクライアントとサーバーの保護については、Auth for MCPをお読みください。
- サードパーティ統合：組織に代わってユーザーを認証するパートナーアプリケーション、SaaSプラットフォーム、外部サービスなどです。これらのアプリケーションは独自のクライアントメタデータと暗号キーを自ら管理するため、シークレットを共有することなく、個別に更新やキーのローテーションを行えます。
CIMD の例
以下は、パブリック MCP クライアントの CIMD の例です。"token_endpoint_auth_method": "none" が指定されています。
https://example-client.com/mcp-metadata.json
CIMDの手動登録と動的登録の比較
次の表は、CIMDの手動登録と動的登録を比較したものです。動的CIMDクライアントの上限
各テナントで保持できる動的に登録されたCIMDクライアントは、最大500件です。この上限の対象となるのは、アプリケーションがランタイムに自ら登録したクライアントのみで、テナント管理者が手動でインポートしたCIMDクライアントは対象外です。 動的に登録されたCIMDクライアントは、テナント全体のアプリケーションのエンティティ上限にもカウントされます。そのため、1件ごとに両方の上限枠を1つずつ消費します。 動的CIMDクライアントの上限は、テナントごとに調整できます。上限の変更をリクエストするには、Auth0 Supportにお問い合わせください。仕組み
Auth0における手動CIMD登録の仕組みについて説明します：- CIMDの手動登録
- 動的な手動CIMD登録
次の図は、CIMDの手動登録フローの全体像をエンドツーエンドで示しています。
フェーズ1：登録
CIMDの手動登録では、テナント管理者が外部でホストされているCIMDをAuth0にインポートして、アプリケーションを登録します。- アプリケーションの作成：テナント管理者は、次のいずれかの方法でAuth0にCIMDアプリを作成します。
- Auth0 Dashboardで ［Import from URL］ を選択する
external_client_idを指定して、/registerエンドポイントにPOSTリクエストを送信する
- メタデータの取得：Auth0はクライアントのドメインに
GETリクエストを送信し、CIMD (client.json) を取得します。 - セキュリティのバリデーション：Auth0はCIMD URLを対応付けたうえで、CIMD URLのバリデーションルールに照らして検証し、CIMD自体もCIMDのバリデーションルールに照らして検証します。この過程では、
external_client_idがCIMD URLと一致するかどうかなどが確認されます。 - 永続化：検証が完了すると、Auth0はクライアントメタデータをデータベースに保存します。
- 確認：Auth0が成功のレスポンスを返します。これで、アプリケーションがCIMDクライアントとしてAuth0に登録されました。
フェーズ2：認可
登録後、アプリケーションはOAuthフローの中で、CIMD URLを自身のアイデンティティとして使用します。- ユーザーによるタスクの開始：ユーザーが、アプリケーションからAPIへのアクセスを必要とするタスクを開始します。
- 認可リクエスト：アプリケーションは、CIMD URLを
client_idとして指定し、Auth0認可サーバーにリクエストを送信します。 - クライアントの解決：Auth0認可サーバーはデータベースを照会し、渡されたURL (
client_id) を保存済みのクライアント設定 (external_client_id) に解決します。 - ユーザーの同意：Auth0はユーザーに同意画面を表示します。この画面では、CIMDメタデータから取得した
client_nameによってアプリケーションが示されます。 - リダイレクト：ユーザーが同意すると、Auth0は認可コードを付けてユーザーをアプリケーションにリダイレクトします。
- コードの交換：アプリケーションは、トークンエンドポイントで認可コードをアクセストークンと交換します。
- 認可の完了：Auth0認可サーバーは、
client_idにCIMD URLが設定されたアクセストークンを返します。これで、アプリケーションはユーザーに代わってAPIにアクセスできるようになります。