MCP 認可の新仕様(2025-11-25)で登場のCIMDについて
MCPの新仕様(2025-11-25)の大きなアップデートの一つであるCIMD(Client ID Metadata Documents)について自分なりに調べた内容を書きます。
背景
MCPの認可の問題の一つがクライアント登録です。OAuthでは、事前にクライアント登録することでクライアントと認可サーバーの信頼関係を構築します。こうすることによって、クライアントを偽装されて悪意のあるアプリケーションに許可を与えてしまったり、リダイレクトURLを偽装されて攻撃者に認可コードが盗まれるということが発生するのを防ぎます。
しかし、事前にクライアント登録をするモデルはMCPとの相性が悪いです。なぜなら、AI Agentの世界では、どのクライアントとどのサーバーが接続するかは未知数で、その接続数も膨大だからです。
従来のOAuthの考え方では、例えばWebアプリがGoogleカレンダーの情報にアクセスするという設定であれば、アプリの開発者がGoogleカレンダーのリソースアクセスのためのクライアント登録を一度実行すればそれで済みました。しかし、AI Agentはユーザーが自分で接続するサーバーを決めます。ここが大きな違いです。
この問題を解決するために、一つ前の仕様(2025-06-18)ではDCR(Dynamic Client Registration)(RFC 7591)という仕組みを使っていました。
しかし、DCRには運用上の問題があり、今回の新仕様ではCIMDという仕組みが採用されました。
DCRとは
DCRは、事前にクライアント登録をするのではなく、認可フローのタイミングで登録をします。
こうすることで、事前に登録するという手間をなくします。
認可サーバーに次のようなリクエストをします
POST /register
{
"client_name": "My App",
"redirect_uris": ["https://myapp.com/callback"],
"grant_types": ["authorization_code"]
}
認可サーバーはこれを受け取り、次のようなレスポンスを返します。
そして、クライアントIDとリダイレクトURLなどの情報を保存しておきます
HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"client_id": "s6BhdRkqt3",
"client_secret": "ZJYCqe3GGRvdrudKyZS0XhGv_Z45DuKhCUk0gBR1vZk",
"client_secret_expires_at": 1577858400,
"client_name": "My App",
"redirect_uris": ["https://myapp.com/callback"],
"grant_types": ["authorization_code"],
"token_endpoint_auth_method": "client_secret_basic",
"response_types": ["code"],
"scope": "read write",
"registration_access_token": "this.is.an.access.token.value.ffx83",
"registration_client_uri": "https://server.example.com/register?client_id=s6BhdRkqt3"
}
その後、認可リクエスト時に、リクエストに含まれるクライアントIDとリダイレクトURLと、認可サーバーが保存しているものを比較して検証することでなりすましを防ぎます。
GET /authorize?client_id=abc123&redirect_uri=https://myapp.com/callback
DCRの課題
問題点1. データベースが無限に増大する
ユーザーごとに毎回登録するため、データベースが無限に増大していきます。同じユーザーでもデバイスが異なったりするごとにクライアント登録をすることも原因です。
問題点2. DoS攻撃に弱い
誰でもクライアント登録のリクエストができるため、DoS攻撃の対象になります。
これらの課題感から、DCRはMCPにはミスマッチであるとされています。
また、上記の課題が原因とも思われますが、認可サーバーがDCRに対応していないことが多いという現状もブロッカーになっています。
CIMDによる解決
CIMDはDCRの課題を解決すべく提案されている仕様です。現在はDraft中です。
CIMDは、クライアント情報をHTTPS URLでホストし、認可サーバーがそこにクライアント情報をとりにいくというモデルです。
例えばこんなURLでクライアント情報をホストします
client_id = "https://app.example.com/oauth/client-metadata.json"
このURLでは、次のようなクライアント情報を公開しています
{
"client_id": "https://app.example.com/oauth/client-metadata.json",
"client_name": "My Application",
"client_uri": "https://app.example.com",
"logo_uri": "https://app.example.com/logo.png",
"redirect_uris": [
"http://localhost:3000/callback"
],
"grant_types": ["authorization_code"],
"response_types": ["code"],
"token_endpoint_auth_method": "none"
}
CIMDのフローは次のようなイメージです
https://auth0.com/blog/cimd-vs-dcr-mcp-registration/
- 認可サーバーへのリクエスト時に
client_id = https://...のようにクライアントIDとしてURLを付与します。 - 認可サーバーはそのURLへクライアントメタデータを取りに行きます
- メタデータを検証します
- ユーザーへ同意画面を表示します
- 同意されると認可コードを返します
- 以降、通常の認可コードを用いたOAuthコードグラントのフローが走る
攻撃者はクライアントメタデータを改竄する手段をもたいないため、なりすますことができません。
Auth0のこちらのブログでは、おもしろいアナロジーでDCRとCIMDの違いを説明しています。
厳重なオフィスに入館する人(クライアント)と考えた時に、DCRは受付で長い申請書(メタデータ)を記入して秘書(認可サーバー)がそれを許可すしてから来館カードをもらうイメージです。このとき申請書はキャビネットに保存されていきます。対して、CIMDは免許証(メタデータ)を警備員(認可サーバー)が確認するイメージです。
毎回申請するのではなく、クライアント側が自分の安全な身元情報を開示して、認可サーバーはそれを読み取るだけという手順になります。
新仕様(2025-11-25)について
2025-11-25では、DCRはMAYになり、CIMDと事前登録を組み合わせる方式が推奨(SHOULD)されています。
DCRがCIMDに代わっただけでなく、事前登録についても明示的にSOULDとして記述されたことは大きいと考えています。これまでは明示的な記述がなかったために、クライアントによっては事前登録ができないものが多くありました。参照↓
これからについて
私は、各種クライアントや認可サーバーのサービスがCIMDに対応するのを待ちたいかなと思っています。
あとは、自分のMCPの認証認可構築を体験できるリポジトリにも2025-11-25版に準拠した実装を追加しないとなーと思っています
Discussion