In Silico

AIエージェント

MCPのDCRとCIMDの違い：クライアント登録が変わる理由と残るリスク

2026/10/26 （更新: 2026/11/3）

🤖 AIを使用して執筆

  • MCP
  • OAuth
  • 認可
  • CIMD
  • DCR
  • 動的クライアント登録
  • Keycloak
  • VS Code
  • AT Protocol
  • SEP-991
  • リダイレクト URI
  • クライアント ID
  • 認可サーバー
  • 認可コード
  • 同意画面
  • ループバック
  • なりすまし
  • SSRF
  • ドメイン
  • Bluesky
  • IETF
  • Linux Foundation
  • Claude Code
  • Okta
  • arXiv
  • CVE
目次
背景・問い・要点
背景

ネットワーク越しにツールを提供するサーバーを運用し、利用者の代わりにそのサーバーを呼ぶエディタやコマンドラインのツール（以下、クライアント）を受け入れる開発者を考える。運用者はクライアントの作り手と事前に会っていない。利用者の許可を扱う専用のサーバーを認可サーバーと呼び、認可サーバーはクライアント ID という文字列で各クライアントを見分ける。利用者が同意画面（どのクライアントに何を許すかを利用者に確かめる画面）で許可すると、認可サーバーは認可コードを発行する。認可コードは、クライアントがアクセス用の資格情報と交換する一回限りの文字列である。認可サーバーは認可コードを、リダイレクト URI と呼ぶ送り先の URL へ送る。

事前に会っていないクライアントにクライアント ID を渡す方法の一つは、登録の窓口を誰にでも開くことである。クライアントは窓口に名前とリダイレクト URI を申告し、新しいクライアント ID を受け取る。窓口は申告者を確かめないので、悪意のあるプログラムも自分の URL をリダイレクト URI として登録でき、利用者が許可すると認可コードはそのプログラムへ届く。認可サーバーの登録の記録も際限なく増える。もう一つの方法では、クライアントが自分の URL に文書を置き、認可サーバーがその文書を取りに行ってリダイレクト URI を読む。

MCP（Model Context Protocol）は、クライアントとツールを提供するサーバーの間のやりとりを定める仕様である。本稿は、MCP の仕様が、認可の標準である OAuth の上で、前者の動的クライアント登録（DCR、Dynamic Client Registration）から後者の Client ID Metadata Document（CIMD）へ推奨の方式を移した変更を取り上げる。具体物として、VS Code が公開している文書と、Keycloak の実装を読む。この二つを選んだのは、仕様の作り手が変更の理由を一次資料に書いており、読者が文書を開いて中身を確かめられるからである。

問い

MCP のクライアント登録が動的クライアント登録から Client ID Metadata Document へ移ると、リダイレクト URI を決める者と認可サーバーの設定はどう変わり、どのリスクが変わらないのか。

要点

DCR では登録者が、CIMD ではクライアント ID の URL のドメインの持ち主がリダイレクト URI を決め、認可サーバーはどのドメインを信頼するかを方針として決める。ローカルで動くクライアントのなりすましは、どちらの方式でも登録だけでは防げない。

arXiv の論文の測定では、DCR を試験できた 119 のサーバーのうち 114 が、匿名の登録者が送った任意のリダイレクト URI を受け付けた。MCP の仕様は 2025-11-25 の版で CIMD を推奨の方式に加え、2026-07-28 の版で DCR を非推奨にした。仕様の作り手は、ローカルで動くクライアントでは CIMD も DCR と同じリスクを持つと書く。

モデル・例示

VS Code が認可を受けるまでを、二つの方式で並べる

二つの方式の違いは、認可サーバーがリダイレクト URI を照らす記録を誰が書くかにあり、それで攻撃者の URI が通るかが分かれる。記録がループバックの URI を許すと、端末上の攻撃者の要求はどちらの方式でも通る。VS Code が、ある MCP サーバーの認可サーバーから認可コードを受け取る場面を考え、そこまでを二つの方式で順に追う。利用者のログインと同意の手順は、どちらの方式でも同じなので省く。

動的クライアント登録では、VS Code は先に登録の窓口へ申告し、認可サーバーが発行したクライアント ID を使って認可を求める。

  1. VS Code認可サーバー1. 登録の窓口に、名前とリダイレクト URI を送る
  2. 認可サーバー2. 申告をそのまま登録の記録に書き、クライアント ID を作る
  3. 認可サーバーVS Code3. 作ったクライアント ID を返す
  4. VS Code認可サーバー4. そのクライアント ID とリダイレクト URI を付けて認可を求める
  5. 認可サーバー5. リダイレクト URI を登録の記録と照らす。一致する
  6. 認可サーバーVS Code6. 認可コードをリダイレクト URI へ送る

Client ID Metadata Document では、登録の手順が無い。VS Code は、自分の文書の URL https://vscode.dev/oauth/client-metadata.json をクライアント ID としてそのまま使う。文書の redirect_uris には、http://127.0.0.1:33418/ と https://vscode.dev/redirect の二つが並ぶ1。前者の 127.0.0.1 はループバックのアドレスで、端末が自分自身を指す。Keycloak の手引きによれば、デスクトップ版の VS Code は利用者の端末に HTTP サーバーを立て、このループバックのアドレスで認可コードを受け取る2。

  1. VS Code認可サーバー1. 文書の URL をクライアント ID にして認可を求める
  2. 認可サーバーvscode.dev2. クライアント ID の URL から文書を取りに行く
  3. vscode.dev認可サーバー3. 名前と redirect_uris を書いた文書を返す
  4. 認可サーバー4. リダイレクト URI を文書の一覧と照らす。一致する
  5. 認可サーバーVS Code5. 認可コードをリダイレクト URI へ送る

二つの図で、認可サーバーがすることは同じである。求められたリダイレクト URI を一つの記録と照らし、一致すれば認可コードを送る。違うのは、その記録がどこにあり、誰が書いたかである。

動的クライアント登録Client ID Metadata Document
クライアント ID認可サーバーが発行する文字列。サーバーごとに違うクライアントが置いた文書の URL。どのサーバーでも同じ
照らす記録の場所認可サーバーの登録の記録クライアント ID の URL にある文書
記録を書く者登録の窓口に申告した者その URL のドメインの持ち主
事前の手順認可サーバーごとに登録する無い

記録を書く者の違いは、悪意のあるプログラム（以下、攻撃者）が同じ手順で認可コードを狙うと現れる。動的クライアント登録では、攻撃者も登録の窓口に申告できる。

  1. 攻撃者認可サーバー1. 登録の窓口に、自分のドメインの URL をリダイレクト URI として送る
  2. 認可サーバー攻撃者2. 登録者を確かめず、新しいクライアント ID を返す
  3. 攻撃者利用者3. そのクライアント ID を使った認可のリンクを開かせる
  4. 利用者認可サーバー4. ログインし、同意画面で許可する
  5. 認可サーバー攻撃者5. 記録にある攻撃者のドメインへ認可コードを送る

照らす記録を攻撃者が書いたので、認可サーバーは攻撃者の URI を記録と一致すると判定する。Client ID Metadata Document では、攻撃者が VS Code の文書の URL をクライアント ID として名乗り、自分のドメインをリダイレクト URI に付けても、そのドメインは vscode.dev の文書に無い。認可サーバーは誤りを返し、認可コードを出さない。文書を書き換えられるのは vscode.dev を管理する者だけで、認可サーバーは HTTPS の証明書で vscode.dev のサーバーを確かめたうえで文書を受け取る。

ただし、攻撃者が利用者の端末の上で動いているときは、Client ID Metadata Document でも止まらない。

  1. 端末上の攻撃者1. 利用者の端末で 127.0.0.1 の 33418 番ポートを待ち受ける
  2. 端末上の攻撃者利用者2. VS Code の client_id と redirect_uri http://127.0.0.1:33418/ を付けた認可のリンクを開かせる
  3. 利用者認可サーバー3. ログインする
  4. 認可サーバーvscode.dev4. client_id の URL から文書を取りに行く
  5. vscode.dev認可サーバー5. 文書を返す。redirect_uris にその URI がある
  6. 認可サーバー利用者6. 同意画面に Visual Studio Code の名前と、送り先のホスト 127.0.0.1 を出す
  7. 利用者認可サーバー7. 許可する
  8. 認可サーバー端末上の攻撃者8. 127.0.0.1 の 33418 番ポートへ認可コードを送る

文書がこのループバックの URI を許しているので、認可サーバーは一致すると判定し、同意画面のクライアント名も正しい。利用者に手がかりを与えるのは、送り先のホストが 127.0.0.1、つまり利用者自身の端末だという表示だけで、その表示はどのプログラムが待ち受けているかを示さない。

この例から言えること

  1. 二つの方式の違いは、認可サーバーが照らす記録の場所と書き手にある。動的クライアント登録では認可サーバーの中の記録を登録者が書き、Client ID Metadata Document ではクライアント ID の URL にある文書をそのドメインの持ち主が書く。
  2. 動的クライアント登録では、記録を攻撃者も書けるので、攻撃者の URI も一致と判定される。Client ID Metadata Document では、攻撃者は他人のドメインの文書を書き換えられないので、攻撃者の URI は一致せず、認可コードは出ない。
  3. 記録が http://127.0.0.1:33418/ のようなループバックの URI を許すと、どちらの方式でも、端末上の攻撃者の要求は一致と判定される。待ち受けているプログラムが正規のクライアントかは、認可サーバーにも利用者にも分からない。

MCP の仕様は、推奨の登録方式を Client ID Metadata Document へ移し、動的クライアント登録を非推奨にした

MCP の仕様は、2026-07-28 の版で動的クライアント登録を非推奨にし、新しい実装には Client ID Metadata Document を使うよう勧めた34。MCP は、AI のアプリケーションを外部のツールやデータにつなぐための仕様として Anthropic が公開し、その約 1 年後の 2025-12-09 に Linux Foundation の下の Agentic AI Foundation へ寄贈した。寄贈の時点で、稼働する公開の MCP サーバーは 10,000 を超え、Python と TypeScript の SDK（Software Development Kit）は月に 9,700 万回以上ダウンロードされていた5。

変更は段階を踏んでいる。arXiv で公開された測定の論文がまとめた経緯では、2025-03-26 の版が動的クライアント登録を推奨（SHOULD）として導入した6。2025-11-25 の版は Client ID Metadata Document を推奨の方式として加え7、2026-07-28 の版は動的クライアント登録を非推奨にした4。削除は「2027-07-28 以降に出る最初の改訂」より前には起きない8。それまで動的クライアント登録は、Client ID Metadata Document に対応しない認可サーバーとの後方互換のために使える3。

クライアントは次の順に調べ、最初に当てはまった方式を使う3。CIMD への対応は認可サーバーのメタデータの client_id_metadata_document_supported で、登録の窓口は registration_endpoint で示される。

  1. 事前登録の情報がある？
    はい
    事前登録の情報を使う
    いいえ
  2. メタデータが CIMD への対応を示す？
    はい
    CIMD を使う
    いいえ
  3. メタデータに登録の窓口がある？
    はい
    DCR を使う
    いいえ
  4. 利用者に入力を求める

認可サーバーの運用者がメタデータで Client ID Metadata Document への対応を示せば、対応するクライアントは登録の窓口を使わなくなる。仕様によれば、この方式のクライアント ID は認可サーバーをまたいで使え、認可サーバーを替えても登録し直す必要がない3。運用者にとっての判断の基準は、受け入れたいクライアントが Client ID Metadata Document に対応しているかと、自分の認可サーバーの対応が本番で使える段階にあるかである。対応しないクライアントを受け入れ続ける間は、登録の窓口も開いたままになる。

同じ方向へ動く者はほかにもいる。IETF（Internet Engineering Task Force）の OAuth 作業部会では、Okta の Parecki らが Client ID Metadata Document の草案を出している9。Bluesky の AT Protocol は、クライアント ID を公開のメタデータを指す URL とする方式をすでに使っている10。オープンソースの ID・アクセス管理ソフトウェアである Keycloak（リポジトリは 2013 年作成、GitHub のスター 37,434、2026-10-20 取得）11は、26.6.0 でこの方式を実験的機能として加えた12。26.7.0 では、既にあった VS Code の手順に加えて、Claude Code を MCP クライアントとしてつなぐ手順を載せた13。Microsoft のエディタである VS Code は、自分の文書を公開している1。

動的クライアント登録では匿名の登録者がリダイレクト URI を決められ、測定されたサーバーの多くは任意の URI を受け付けていた

動的クライアント登録では登録の窓口に申告した者がリダイレクト URI を決め、多くの MCP サーバーがその申告を確かめずに受け付けていた。測定は、登録者が照合の記録を書き、照合が攻撃者を止めない状態が、多くの実際のサーバーで成り立っていたことを示す。arXiv で公開された Zhou らの測定は、稼働する遠隔の MCP サーバー 7,973 を見つけた。そのうち 2,428 が OAuth を使い、さらにそのうち 1,118 が登録の窓口を公開していた6。

著者らは、登録の窓口を公開した 1,118 のサーバーから、重複するものや接続できないもの、企業のアクセス制御で閉じているものなどを手作業で除き、残った 119 のサーバーを詳しく調べた6。119 はすべて動的クライアント登録に対応するサーバーである。119 のうち 114 は、匿名の登録者が送った任意のリダイレクト URI を受け付けた。72 は、同意画面にリダイレクト URI を表示していなかった。論文が挙げた CVE（Common Vulnerabilities and Exposures）9 件のうち 7 件が、任意のリダイレクト URI を受け付ける欠陥に当たる。

119 は動的クライアント登録に対応するサーバーから選んだ部分集合なので、114 を MCP サーバー全体での割合として読めない6。サーバーの発見は FOFA と Shodan に索引されたものに限られ、検出器の精度は 85.75% である。著者らは対策として、Client ID Metadata Document への移行と、同意画面でリダイレクト URI を常に表示することを挙げた。

認可サーバーの負担も理由に挙がっている。Client ID Metadata Document を MCP に取り入れたのは、変更提案 SEP-991（SEP は Specification Enhancement Proposal、2025 年、Carleton と Parecki）である。SEP-991 は、動的クライアント登録では認可サーバーが際限なく増える登録の記録を管理し、期限切れを扱い、登録者が自分で申告したメタデータを信じることになると書く14。

Client ID Metadata Document ではドメインの持ち主がリダイレクト URI を決め、認可サーバーは信頼するドメインを方針で決める

Client ID Metadata Document ではリダイレクト URI がクライアントの URL にある文書から来るので、認可サーバーは登録の記録を持たず、どのドメインを信頼するかを方針として決める。クライアント ID はパスを含む HTTPS の URL でなければならず、その URL はクライアントのメタデータを書いた JSON の文書を指す3。文書には client_id・client_name・redirect_uris が必須で、client_id は文書の URL と完全に一致しなければならない。認可サーバーは文書を取りに行くことを推奨され、URL との一致と、認可の要求にあるリダイレクト URI が文書の一覧にあることの検証は必須である。

VS Code の文書は、client_id に文書自身の URL を、client_name に Visual Studio Code を書く1。redirect_uris は http://127.0.0.1:33418/ と https://vscode.dev/redirect の二つで、token_endpoint_auth_method は none である。この文書を書き換えられるのは vscode.dev を管理する者である。照合の記録を書く者がリダイレクト URI を決めるので、ここで決めるのも vscode.dev を管理する者である。

作り手は SEP-991 で設計の理由を書いた14。対象は、クライアントの作り手がサーバーを知らず、サーバーの運用者もクライアントを知らない場合で、SEP-991 は MCP ではクライアントよりサーバーのほうがはるかに多いと書く。信頼は事前の登録からではなく、クライアントのドメインから来る。HTTPS の URL は識別子であると同時に信頼の起点になり、認可サーバーはメタデータのリダイレクト URI を、攻撃者の申告ではなくクライアントが管理するものとして扱える。

運用者が決めることも変わる。SEP-991 は、開いたサーバーは任意の HTTPS のクライアント ID を受け付けてよく、守るサーバーは信頼するドメインや特定のクライアントに絞れると書く14。MCP の仕様は、ドメインに基づく信頼の方針を実装してよいとする15。IETF の草案は方針の例として、ドメインの経過日数、最初の 100 人の利用者への追加の警告、*.example.com のような許可リストを挙げる9。

代償は三つある。

  1. クライアントは HTTPS の URL に文書を置く。 SEP-991 は、デスクトップのアプリケーションだけでは済まなくなると認めたうえで、負担は小さいと見込む14。この代償は恒久的で小さい。ただし IETF の草案は、安定した公開の URL を持たないクライアント、たとえば開発者の端末で開発中のクライアントにはこの方式が向かないと書き、開発用のクライアント ID を発行するサービスを用意する道を示す9。
  2. 認可サーバーは、知らない相手が指定した URL を取りに行く。 攻撃者が認可サーバーに内部ネットワークの URL を取りに行かせる攻撃（SSRF、Server-Side Request Forgery）が起こりうる14。この代償も恒久的だが、対策は決まっている。草案は、特別な用途の IP アドレスに解決される URL を取りに行くことを禁じ、ループバックの例外は開発用に限る9。
  3. Keycloak の対応は実験的機能である。 Keycloak の手引きは、動的クライアント登録を「対応」、Client ID Metadata Document を「実験的」とし、将来の版で互換性を壊す変更がありうると書く2。有効にするには --features=cimd を付けて起動する。この代償は、機能が実験的機能から外れた時点で解消する。

ループバックへのリダイレクトはどちらの方式でも守れず、仕様は同意画面の表示に防御を置く

127.0.0.1 などループバックへのリダイレクトは動的クライアント登録でも Client ID Metadata Document でも守れず、仕様は同意画面でホスト名を表示することに防御を置いている。SEP-991 によれば、攻撃者は正規のクライアントの文書の URL をクライアント ID として示し、正規のクライアントと同じローカルのポートで待ち受ければ、利用者が許可したときに認可コードを横取りできる14。記録が許すループバックの URI では、照合が通るからである。認可サーバーは正しい文書を見て、利用者は正しいクライアント名を見る。SEP-991 は、この場面では新しい方式も動的クライアント登録と同じリスクを持ち、完全な対策は提案の範囲外だとする。

MCP の仕様は、認可サーバーへの要求を三つ置く15。リダイレクト URI のホスト名をはっきり表示することは必須、ループバックにしかリダイレクトしないクライアントに追加の警告を出すことは推奨、追加の証明を求めることは任意である。SEP-991 は、端末の証明として iOS の DeviceCheck や Android の Play Integrity を挙げるが、どこでも使えるものではないとする14。前節の測定では、試験した動的クライアント登録のサーバー 119 のうち 72 が、同意画面にリダイレクト URI を表示していなかった6。

SEP-991 は、端末の証明を使わない方法として、クライアントの作り手が運用するサーバーが短い期限の JWT（JSON Web Token）に署名する方式も挙げ、この方式は攻撃の手間を増やしてリスクを減らすが、除き切れないとする。攻撃者は正規のクライアントの署名サーバーへ要求を中継できるからである14。本稿は、ループバックで待ち受けるプログラムが正規のクライアントかを認可サーバーが確かめられない状態は、端末の証明が広く使えるようになるまで続くと考える。

運用者が決める設定のうち、ループバックへのリダイレクトに関わるのは、どのドメインのクライアントを受け入れるかと、どの形のリダイレクト URI を許すかである。Keycloak は次の設定を持つ2。

手引きは VS Code のデスクトップ版を例に、後の二つを切るよう書いている2。リダイレクト URI が vscode.dev ではなく 127.0.0.1 にあるので同じドメインへの制限を外し、VS Code は公開クライアントなので機密クライアントだけを許す設定も外す。同じ例で、信頼するドメインには vscode.dev・127.0.0.1・code.visualstudio.com を並べる。一方で Claude Desktop はリダイレクト URI を claude.ai のドメインに置くので、手引きは同じドメインへの制限を有効にできるとしている2。

例外もある。クライアントとサーバーに事前の関係があれば、仕様は事前登録を使う場面としている3。AT Protocol は開発のために http://localhost のクライアント ID を例外として認め、本番の環境でも対応を勧めているが、対応は任意である10。草案は、開発に限ってループバックの文書を取りに行くことを認め、本番では禁じる9。

出典15件

  1. Microsoft「client-metadata.json」vscode.dev, 2026（2026-10-20 取得）. https://vscode.dev/oauth/client-metadata.json — VS Code が公開する文書の中身。クライアント名、二つのリダイレクト URI、認証方式 none。 ↩ ↩2 ↩3

  2. Keycloak「Integrating with Model Context Protocol (MCP)」keycloak.org, 2026. https://www.keycloak.org/securing-apps/mcp-authz-server — 対応が実験的であること、信頼するドメインの既定の拒否、同じドメインへの制限、機密クライアントの限定。 ↩ ↩2 ↩3 ↩4 ↩5

  3. Model Context Protocol「Client Registration」MCP Specification 2026-07-28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration — 三つの登録方式と選ぶ順序、文書の必須項目と認可サーバーの検証、動的クライアント登録を非推奨とする注記。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. Model Context Protocol「Changelog」MCP Specification 2026-07-28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/changelog — 2026-07-28 版での動的クライアント登録の非推奨化。 ↩ ↩2

  5. Anthropic「Donating the Model Context Protocol and establishing the Agentic AI Foundation」2025. https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation — MCP の寄贈先、公開サーバー数と SDK のダウンロード数。 ↩

  6. Zhou ほか「A First Measurement Study on Authentication Security in Real-World Remote MCP Servers」arXiv, 2026. https://arxiv.org/abs/2605.22333 — 登録の窓口を公開するサーバーの数、試験した 119 の欠陥、発見方法と検出精度の限界。 ↩ ↩2 ↩3 ↩4 ↩5

  7. Model Context Protocol「Changelog」MCP Specification 2025-11-25, 2025. https://modelcontextprotocol.io/specification/2025-11-25/changelog — Client ID Metadata Document を推奨の登録方式として加えたこと。 ↩

  8. Model Context Protocol「Deprecated Features」MCP Specification 2026-07-28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/deprecated — 動的クライアント登録を非推奨にした版と、削除が可能になる最も早い時期。 ↩

  9. Parecki, Smith「OAuth Client ID Metadata Document」IETF, draft-02, 2026. https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/ — 公開の URL を持たないクライアントに向かないこと、SSRF の禁止事項、信頼の判断の例。 ↩ ↩2 ↩3 ↩4 ↩5

  10. Bluesky「AT Protocol OAuth」atproto.com, 2026. https://atproto.com/specs/oauth — クライアント ID を公開のメタデータを指す URL とする方式と、開発用の localhost の例外。 ↩ ↩2

  11. Keycloak「keycloak/keycloak」GitHub（2026-10-20 取得）. https://github.com/keycloak/keycloak — リポジトリの作成年（2013 年）とスター数（37,434）。 ↩

  12. Keycloak「Keycloak 26.6.0」GitHub Releases, 2026. https://github.com/keycloak/keycloak/releases/tag/26.6.0 — Client ID Metadata Document を実験的機能として加え、MCP 2025-11-25 以降の認可サーバーとして使えるようにしたこと。 ↩

  13. Keycloak「Keycloak 26.7.0」GitHub Releases, 2026. https://github.com/keycloak/keycloak/releases/tag/26.7.0 — 26.7.0 で Claude Code の接続手順を加えたこと。 ↩

  14. Carleton, Parecki「SEP-991: Enable URL-based Client Registration using OAuth Client ID Metadata Documents」MCP, 2025. https://modelcontextprotocol.io/seps/991-enable-url-based-client-registration-using-oauth-c — 作り手の設計理由と、ローカルのなりすまし・SSRF・クライアントの負担。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  15. Model Context Protocol「Security Considerations」MCP Specification 2026-07-28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations — 文書だけではローカルのなりすましを防げないこと、ホスト名の表示が必須で警告は推奨であること。 ↩ ↩2

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。