> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Client ID Metadata Document（CIMD）による登録
> Auth0におけるClient ID Metadata Document（CIMD）による登録について、その利点やユースケース、手動CIMDと動的CIMDの仕組みを説明します。
> [!WARNING]
>
> **Dynamic CIMD Registration機能は現在、です。**
外部でホストされているClient ID Metadata Document (CIMD) をURLからインポートして、Auth0にアプリケーションを登録します。CIMDは、自社のドメイン上でホストされる、クライアントメタデータを含むJSONファイルです (例：`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で登録できるのは[サードパーティアプリケーション](/docs/ja-jp/get-started/applications/third-party-applications)のみで、これらには[強化されたセキュリティ対策](/docs/ja-jp/get-started/applications/third-party-applications/security-controls.md)が適用されます。詳細については、[CIMDでアプリケーションを登録する](/docs/ja-jp/get-started/auth0-overview/create-applications/register-applications-with-cimd.md)をお読みください。
動的に登録されたCIMDクライアントについては、テナント管理者が[アプリケーションプロファイル](/docs/ja-jp/get-started/applications/application-profiles.md)を使用して、リフレッシュトークンの有効期間やOrganizationsの動作などのアプリケーション設定を一貫して適用できます。
CIMDクライアントは、テナントの**Create Permissive Third-Party Clients by Default**設定にかかわらず、常に`third_party_security_mode: "strict"`で登録されます。CIMDクライアントでは許容モードを使用できません。厳格モードのサードパーティアプリケーションは[ルールをサポートしていない](/docs/ja-jp/get-started/applications/third-party-applications/security-controls.md#features-not-supported)ため、テナントに有効なルールがあると、CIMDクライアントのログインフローは失敗します。ルールを使用している場合は、CIMDクライアントを登録する前に[アクションへ移行](/docs/ja-jp/customize/actions/migrate/migrate-from-rules-to-actions.md)してください。
CIMDクライアントは、登録後に手動と動的を切り替えることはできません。切り替えるには、クライアントを削除してから再登録してください。
## 主な利点
手動CIMD登録には、次のような利点があります。
1. MCPクライアントのCIMDへの登録は、デプロイメントごとに一度だけで済みます。そのデプロイメントのすべてのインスタンスで、同じ登録認証情報が使用されます。
2. 登録には、漏洩のおそれがある共有の対称シークレットではなく、非対称暗号 (公開鍵/秘密鍵) が使用されます。
3. アプリケーションの所有者は、CIMDでクライアントメタデータを直接管理できます。Auth0は登録時に、これらのプロパティを内部の設定に自動的に対応付けます。
4. CIMDのURLは、監査ログ内で人が読める識別子として機能します。そのため、特定のMCPツールサーバーやホストからのリクエストの発信元を簡単に確認できます。
## ユースケース
手動CIMD登録の一般的なユースケースは次のとおりです。
* MCPクライアント：CIMDでの登録は、デプロイメントごとに一度行うだけで済みます。そのデプロイメントのすべてのインスタンスで同じ登録認証情報を使用します。Auth0によるMCPクライアントとサーバーの保護については、[Auth for MCP](/ai/docs/ja-jp/mcp/overview.md)をお読みください。
* サードパーティ統合：組織に代わってユーザーを認証するパートナーアプリケーション、SaaSプラットフォーム、外部サービスなどです。これらのアプリケーションは独自のクライアントメタデータと暗号キーを自ら管理するため、シークレットを共有することなく、個別に更新やキーのローテーションを行えます。
## CIMD の例
以下は、パブリック MCP クライアントの CIMD の例です。`"token_endpoint_auth_method": "none"` が指定されています。
```json https://example-client.com/mcp-metadata.json wrap lines theme={null}
{
"client_id": "https://example-client.com/mcp-metadata.json",
"client_name": "Example MCP Tool Server",
"description": "MCP server providing tools for data analysis",
"logo_uri": "https://example-client.com/logo.png",
"application_type": "web",
"grant_types": ["authorization_code", "refresh_token"],
"redirect_uris": [
"https://example-client.com/callback"
],
"token_endpoint_auth_method": "none",
"response_types": ["code"]
}
```
Auth0は[CIMDフィールドを自動的に対応付けて検証します](/docs/ja-jp/get-started/auth0-overview/create-applications/cimd-validation-rules.md#cimd-json-validation-rules)。サポートされているクライアントの種類について詳しくは、「[前提条件](/docs/ja-jp/get-started/auth0-overview/create-applications/register-applications-with-cimd.md#prerequisites)」をお読みください。
## CIMDの手動登録と動的登録の比較
次の表は、CIMDの手動登録と動的登録を比較したものです。
| 機能 | CIMDの手動登録 | CIMDの動的登録 |
| - | - | - |
| **Client ID** | HTTPS URL (例：`https://yourdomain.com/client.json`) | HTTPS URL (例：`https://yourdomain.com/client.json`) |
| **認証** | 非対称キーのみ (シークレットは不使用) | 非対称キーのみ (シークレットは不使用) |
| **アイデンティティの確認** | HTTPSでのホスティングによるドメイン所有権の確認 | HTTPSでのホスティングによるドメイン所有権の確認 |
| **登録のトリガー** | テナント管理者がCIMD URLからアプリケーションをインポート | アプリケーションが初回のOAuthリクエスト時に、ランタイムで自身を登録 |
| **メタデータの管理** | CIMDを信頼できる情報源とし、手動で更新 | CIMDを信頼できる情報源とし、自動で更新 (リアクティブおよびバックグラウンド) |
| **メタデータ変更に対する管理者の審査** | 変更の適用前に管理者が審査・承認 | 管理者の審査なし。検証済みの変更は自動的に適用 |
| **キーのローテーション** | `jwks_uri`で複数のキーに対応。手動で更新 | `jwks_uri`で複数のキーに対応。必要に応じて自動的に解決 |
| **アプリケーションの種類** | サードパーティアプリケーションのみ | サードパーティアプリケーションのみ |
| **主なユースケース** | MCPクライアント、サードパーティ統合 | 手動でのプロビジョニングなしに登録される、大量または一時的なクライアント (AI agentなど) |
## 動的CIMDクライアントの上限
各テナントで保持できる動的に登録されたCIMDクライアントは、最大500件です。この上限の対象となるのは、アプリケーションがランタイムに自ら登録したクライアントのみで、テナント管理者が手動でインポートしたCIMDクライアントは対象外です。
動的に登録されたCIMDクライアントは、テナント全体の[アプリケーションのエンティティ上限](/docs/ja-jp/troubleshoot/customer-support/operational-policies/entity-limit-policy.md#enterprise)にもカウントされます。そのため、1件ごとに両方の上限枠を1つずつ消費します。
動的CIMDクライアントの上限は、テナントごとに調整できます。上限の変更をリクエストするには、[Auth0 Support](https://support.auth0.com/)にお問い合わせください。
## 仕組み
Auth0における手動CIMD登録の仕組みについて説明します：
**CIMDの手動登録**
次の図は、CIMDの手動登録フローの全体像をエンドツーエンドで示しています。
* [フェーズ1：登録](#phase-1-registration)
* [フェーズ2：認可](#phase-2-authorization)
```mermaid theme={null}
%%{init: { "sequence": { "mirrorActors": true }}}%%
sequenceDiagram
rect rgb(240, 248, 255)
Note over Tenant Admin,Auth0: Registration Phase
participant Tenant Admin
participant Auth0
participant Domain
Tenant Admin->>Auth0: Create CIMD app
Auth0->>Tenant Admin: POST /register
(external_client_id = https://.../client.json)
Auth0->>Domain: GET https://.../client.json
Domain-->>Auth0: Client metadata (CIMD JSON)
Auth0->>Auth0: Validate + store client
end
rect rgb(240, 255, 240)
Note over Client,Auth0: Authorization Phase
actor User
participant Client
participant Auth0
User->>Client: User-initiated task
Client->>Auth0: /authorize?client_id = https://.../client.json
(Auth0 resolves client by external_client_id == client_id)
Auth0->>User: Consent screen
(client metadata)
User->>Auth0: Approve
Auth0-->>Client: Authorization code
Client->>Auth0: Exchange code
Auth0->>Client: Complete authorization & redirect to client redirect_uri
Client->>Auth0: Request resource access token with /oauth/token
Auth0-->>Client: Return resource access token
(includes client_id=https://../client.json)
end
```
### フェーズ1：登録
CIMDの手動登録では、テナント管理者が外部でホストされているCIMDをAuth0にインポートして、アプリケーションを登録します。
1. **アプリケーションの作成**：テナント管理者は、次のいずれかの方法でAuth0にCIMDアプリを作成します。
* Auth0 Dashboardで **［Import from URL］** を選択する
* `external_client_id`を指定して、`/register`エンドポイントに`POST `リクエストを送信する
2. **メタデータの取得**：Auth0はクライアントのドメインに`GET`リクエストを送信し、CIMD (client.json) を取得します。
3. **セキュリティのバリデーション**：Auth0はCIMD URLを対応付けたうえで、[CIMD URLのバリデーションルール](/docs/ja-jp/get-started/auth0-overview/create-applications/cimd-validation-rules.md#cimd-url-validation-rules)に照らして検証し、CIMD自体も[CIMDのバリデーションルール](/docs/ja-jp/get-started/auth0-overview/create-applications/cimd-validation-rules.md#cimd-json-validation-rules)に照らして検証します。この過程では、`external_client_id`がCIMD URLと一致するかどうかなどが確認されます。
4. **永続化**：検証が完了すると、Auth0はクライアントメタデータをデータベースに保存します。
5. **確認**：Auth0が成功のレスポンスを返します。これで、アプリケーションがCIMDクライアントとしてAuth0に登録されました。
### フェーズ2：認可
登録後、アプリケーションはOAuthフローの中で、CIMD URLを自身のアイデンティティとして使用します。
1. **ユーザーによるタスクの開始**：ユーザーが、アプリケーションからAPIへのアクセスを必要とするタスクを開始します。
2. **認可リクエスト**：アプリケーションは、CIMD URLを`client_id`として指定し、Auth0認可サーバーにリクエストを送信します。
3. **クライアントの解決**：Auth0認可サーバーはデータベースを照会し、渡されたURL (`client_id`) を保存済みのクライアント設定 (`external_client_id`) に解決します。
4. **ユーザーの同意**：Auth0はユーザーに同意画面を表示します。この画面では、CIMDメタデータから取得した`client_name`によってアプリケーションが示されます。
5. **リダイレクト**：ユーザーが同意すると、Auth0は認可コードを付けてユーザーをアプリケーションにリダイレクトします。
6. **コードの交換**：アプリケーションは、トークンエンドポイントで認可コードをアクセストークンと交換します。
7. **認可の完了**：Auth0認可サーバーは、`client_id`にCIMD URLが設定されたアクセストークンを返します。これで、アプリケーションはユーザーに代わってAPIにアクセスできるようになります。
**動的な手動CIMD登録**
次の図は、動的CIMD登録フロー全体をエンドツーエンドで示しています。
```mermaid theme={null}
sequenceDiagram
actor User
participant CA as Client App
participant AS as Authorization Server
participant CD as Client's Domain (Hosts JSON)
User->>CA: 1. Start Login
CA->>AS: 2. Auth Request (client_id=https://...)
alt Metadata Cached and Fresh
AS->>AS: 3. Retrieve Cached Metadata
else Metadata Missing or Stale
AS->>CD: 3. GET /.../client-metadata.json
CD-->>AS: 4. Returns client-metadata.json
AS->>AS: 5. Validate Metadata (SSRF checks, etc.)
AS->>AS: Create Non-Validated Client Record
end
AS->>User: 6. Show Consent Screen (using client_name)
User->>AS: 7. Approve Consent
AS-->>CA: 8. Redirect with Authorization Code
CA->>AS: 9. Request Token (with Code)
AS-->>CA: 10. Return Access Token
```
動的CIMD登録では、事前に手動で登録する手順を経ることなく、アプリケーションがランタイムに自らをAuth0に登録します。
1. **ログインの開始**：ユーザーがクライアントアプリケーションからログインを開始します。
2. **認可リクエスト**：アプリケーションが自身のCIMD URLを`client_id`として指定し、Auth0認可サーバーに認可リクエストを送信します。
3. **メタデータの解決**：そのクライアントの最新のメタデータがすでにAuth0にキャッシュされている場合は、キャッシュされたコピーを使用し、以降の手順は省略されます。キャッシュがない場合、Auth0はクライアントのドメインに`GET`リクエストを送信し、CIMD (`client-metadata.json`) を取得します。
4. **メタデータの返却**：クライアントのドメインがCIMDを返します。
5. **セキュリティ検証**：Auth0は、SSRFチェックを含む[CIMD URL検証ルール](/docs/ja-jp/get-started/auth0-overview/create-applications/cimd-validation-rules.md#cimd-url-validation-rules)と[CIMD JSON検証ルール](/docs/ja-jp/get-started/auth0-overview/create-applications/cimd-validation-rules.md#cimd-json-validation-rules)に基づいてCIMDを検証し、アプリケーションを未検証のCIMDクライアントとして登録します。
6. **ユーザーの同意**：Auth0はユーザーに同意画面を表示します。この画面では、CIMDメタデータから取得した`client_name`によってアプリケーションが示されます。
7. **同意の承認**：ユーザーが同意リクエストを承認します。
8. **リダイレクト**：Auth0は認可コードを付与して、ユーザーをアプリケーションにリダイレクトします。
9. **トークンリクエスト**：アプリケーションはトークンエンドポイントで認可コードを[アクセストークン](/docs/ja-jp/secure/tokens/access-tokens.md)と交換します。
10. **アクセストークンの返却**：Auth0認可サーバーがアプリケーションにアクセストークンを返します。これにより、アプリケーションはユーザーに代わってAPIにアクセスできるようになります。
## はじめに