# CIMD認可サーバー実装——SSRF対策と信頼ポリシー設計

> MCP仕様2026-07-28でDCRは非推奨になった。Client ID Metadata Documentsを受ける認可サーバーのSSRF防御・5KB上限・キャッシュ・信頼ポリシーの設計点を整理する。

- Canonical: https://kuucorp.com/blog/mcp-cimd-authorization-server-ssrf-trust-policy/
- Date: 2026-10-19
- Last modified: 2026-10-19
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
自社の認可サーバーに、見知らぬMCPクライアントが `client_id=https://…` というURLを持って現れる。認可サーバーはそのURLを自分で取得しに行く。この「外部URLの取得」が、SSRFの入口になる。

MCP仕様 2026-07-28 は Dynamic Client Registration（DCR, RFC 7591）を非推奨とし、Client ID Metadata Documents（CIMD）への移行を求めた。CIMDを受ける側（認可サーバー）に何が増えるのかを、仕様原文に沿って整理する。クライアント登録の全体像と廃止スケジュールは [MCPの非推奨機能インベントリ](/blog/mcp-feature-lifecycle-deprecation-inventory-design/) を、OAuth全体のスコープ設計は [MCPサーバーのOAuth 2.1認可フロー](/blog/mcp-security-oauth-scope-design/) を参照してほしい。

## CIMDはDCRと何が違うのか

> CIMDはクライアントのHTTPS URLを client_id とし、認可サーバーがそのURLのJSONを取得して登録情報とする方式です。事前登録の窓口が不要になります。

DCRでは、クライアントが認可サーバーの `registration_endpoint` に登録要求を送り、認可サーバーが `client_id` を発行して状態を持つ。CIMDでは逆で、クライアントが自分のURLを `client_id` として名乗り、認可サーバーが必要なときに取得する。

仕様が定めるクライアント側の要件は次のとおり。

- `client_id` のURLは `https` スキームで、パス成分を含む（例: `https://example.com/client.json`）
- 文書には最低限 `client_id` / `client_name` / `redirect_uris` を含める
- 文書内の `client_id` は、文書のURLと完全一致させる

クライアントの優先順位は、事前登録済み情報 → CIMD（認可サーバーのメタデータに `client_id_metadata_document_supported` がある場合）→ DCR → ユーザー入力の順だ。CIMDで発行されたクライアントIDは自己ホストのURLなので、認可サーバーが変わっても再登録が要らない。DCRで得た資格情報は、`issuer` 単位で紐付けて保持する必要がある。

エンタープライズの認可サーバーにとっての実利は、登録状態（DBレコード）を持たなくてよい点にある。一方で、外部が指定したURLを取得する責務が新たに発生する。

## 認可サーバーはどこまで取得を制限すべきか

> CIMD文書の取得は認可サーバーからの外向きリクエストです。プライベート・ループバックアドレスを避け、応答は5KB程度に制限するのが仕様の指針です。

MCP仕様は、取得側の認可サーバーに対しSSRFのリスクを考慮するよう求めている（SHOULD）。IETFドラフト（draft-ietf-oauth-client-id-metadata-document-00）の第6章が具体策の根拠になる。

- **取得先の制限**: プライベートアドレスおよびループバックアドレスのURLは取得しない
- **応答サイズ**: クライアントメタデータ文書は最大5KBを目安に制限する
- **検証**: 取得した文書がJSONとして妥当で、必須項目を含み、`client_id` がURLと単純な文字列比較で一致すること（MUST）
- **取得失敗時**: 認可要求を中止する
- **キャッシュ**: HTTPキャッシュヘッダーを尊重する。エラー応答はキャッシュしない
- **シークレット認証の拒否**: `token_endpoint_auth_method` に `client_secret_post` 等を含めない。クライアント認証が必要なら `private_key_jwt` と `jwks_uri` を使う

ドラフトが明記する以上の実装（DNS再バインディング対策、リダイレクト追従の可否、タイムアウト値）は、仕様が値を定めていない。ここは自社の設計判断になる。一般的には、名前解決後のIPを検証してからそのIPへ接続する、リダイレクトを追従しない、取得専用のegressプロキシを経由させる、といった構成が現実的だ。数値は自社のネットワーク方針で決め、仕様の記述と混同しないこと。

## 信頼ポリシーはどう設計するのか

> CIMDで証明できるのはURLのドメイン管理権だけです。どのクライアントにどのスコープを渡すかは、認可サーバー側の信頼ポリシーで別に決めます。

`client_id` の文書を返せることは、そのドメインを管理している証拠にすぎない。そのクライアントが機密データにアクセスしてよい証拠にはならない。MCP仕様は、ドメインベースの信頼ポリシーを認可サーバーが任意で実装できる（MAY）と位置づける。ドラフトの6.4と6.8は、`client_id` のホスト名の表示と、新規登録ドメインへの警告などの独自ヒューリスティクスを挙げている。

設計の軸を3段階に分けると運用しやすい。

1. **許可リスト型**: 管理者が承認したURL・ドメインのみ受理する。社内エージェント基盤向け
2. **段階付与型**: 未知のドメインは低リスクのスコープのみ、承認済みドメインは広いスコープを許す
3. **オープン型**: 任意URLを受理し、同意画面での警告とレート制限で補う。公開SaaS向け

エンタープライズの社内MCPでは、1か2が基本になる。同意画面には `client_name` に加え、`client_id` のホスト名と `redirect_uris` のホスト名を必ず表示する。ドラフトは `redirect_uris` を文書と同一オリジンに制限する方法も示している。`logo_uri` は事前取得してキャッシュすると、審査とトラッキング防止に使える。

localhost のリダイレクトURIは別問題だ。仕様は「CIMDだけではlocalhostのなりすましを防げない」と明記し、認可サーバーに警告表示（SHOULD）、リダイレクトURIのホスト名の明示（MUST）、必要に応じた追加の証明手段（MAY）を求めている。

## 移行時に何を確認すべきか

> DCR非推奨は即時廃止ではありません。ただし新規実装はCIMDを採用し、既存のDCR登録は計画的に棚卸しします。

2026-07-28の変更履歴では、DCRは後方互換のため残るが、新規実装は採用すべきでないとされた。確認項目は次のとおり。

- 認可サーバーのメタデータに `client_id_metadata_document_supported: true` を載せたか
- 取得処理が外向き通信の統制（egress制御・監査ログ）の下にあるか
- DCRを使う既存クライアントを棚卸しし、`application_type`（native / web）を正しく指定させているか
- RFC 9207 の `iss` パラメータを認可応答に含め、クライアントが検証できるようにしたか（mix-up攻撃対策。仕様はMCPクライアントに、存在する `iss` を記録済みissuerと照合することをMUSTとしている）

規模の大きい組織では、社内IdPの前段にCIMD対応のゲートウェイを置き、信頼ポリシーを一箇所で管理する構成が取りやすい。企業管理型の認可との関係は [MCPエンタープライズ認可設計](/blog/mcp-enterprise-managed-authorization-design/) で扱っている。

## 参考

- [Client Registration — MCP Specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration)
- [Authorization Security Considerations — MCP Specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations)
- [Key Changes — MCP Specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
- [OAuth Client ID Metadata Document（IETF Internet-Draft 00）](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00)

## まとめ

CIMDは登録状態を持たない代わりに、認可サーバーへ外部URLの取得責務を課します。SSRF防御（プライベート・ループバック拒否、5KB上限、エラー非キャッシュ）と、ドメインベースの信頼ポリシー、localhost警告の3点を実装して初めて、DCRから安全に移行できます。

MCP認可基盤の移行設計や社内IdPとの統合でお困りの場合は、[KuuのRDEサービス](/services/rde/)にご相談ください。