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

自社の認可サーバーに、見知らぬ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の非推奨機能インベントリを、OAuth全体のスコープ設計は MCPサーバーのOAuth 2.1認可フローを参照してほしい。

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段階に分けると運用しやすい。

許可リスト型: 管理者が承認したURL・ドメインのみ受理する。社内エージェント基盤向け
段階付与型: 未知のドメインは低リスクのスコープのみ、承認済みドメインは広いスコープを許す
オープン型: 任意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エンタープライズ認可設計で扱っている。

参考

まとめ

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

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