CIMDメタデータポリシー

はじめに

MCP 仕様の 2025 年 11 月 25 日版で、MCP を構成する標準仕様セットの一つとして CIMD が採用されました (MCP 2025-11-25 Authorization)。

CIMD 自体の説明は Authlete 社のウェブサイトにあるドキュメント『OAuth Client ID Metadata Document (CIMD)』に譲るとして、この記事では、CIMD の仕組みで取得したクライアントメタデータを調整する方法について考えていきたいと思います。

クライアントの信頼性を確認する方法がない

「CIMD は DCR を置き換える！」と言って、世の中は興奮冷めやらぬ状態です。

DCR は Dynamic Client Registration の略で、文脈により、OpenID Connect Dynamic Client Registration 1.0 または RFC 7591 OAuth 2.0 Dynamic Client Registration Protocol、もしくは両方を指します。

しかし、落ち着いてください。OAuth 2.0 や OpenID Connect で用いる『クライアント ID』の形式を URL にし、その URL から辿れる場所からクライアントメタデータを取得する、という機能は、CIMD を待たずとも、OpenID Federation 1.0 という仕様 (解説記事) で既に実現されています。

OpenID Federation 1.0 については、2023 年 11 月 9 日に開催した『OpenID TechNight vol.20 ~ 分散型 ID 技術勉強会』で詳解していますので、是非ご視聴ください。

1:07:46〜

「リクエストの処理中にクライアントメタデータをリモートサーバからフェッチし、それに基づいてクライアントを動的に登録し、何もなかったかのようにリクエストの処理を継続する」という機能は、認可サーバの実装に大きなインパクトがあります。なにせ、クライアント ID が現れる箇所全てに影響するからです。

クライアント ID は、認可リクエストやトークンリクエストの client_id リクエストパラメータのように分かりやすい場所に現れることもあれば、クライアントアサーション (RFC 7523) やリクエストオブジェクト (RFC 9101) の iss クレーム、ID トークン (OIDC Core) や JWT 認可レスポンス (JARM) の aud クレームなど、個々の仕様の詳細に隠れて気付きにくい場所に現れることもあります。

しかも、動的に取得したクライアントメタデータには有効期限が存在するため、最新情報の再取得処理も実装しなければなりません。

そのため、CIMD 仕様に圧倒されるような気持ちになるかもしれません。

しかしながら、OpenID Federation 1.0 を知っている人達からすると、むしろ逆で、「CIMD 仕様はシンプル過ぎる (セキュリティがガバガバ過ぎる)」と見えています。

CIMD 仕様には、クライアントが信頼できる通信相手であるかどうかを確認する方法が定義されていません。そのため、認可サーバの実装が何らかの独自機能で制限をかけない限り、CIMD をサポートする認可サーバには誰でも勝手にクライアントを登録できてしまいます。これは、トラストチェーンを用いてエンティティ間の信頼関係を築く方法を具体的に定めている OpenID Federation 1.0 とは対照的です。

OpenID Federation 1.0 のトラストチェーン

Authlete の CIMD 実装には『許可リスト』を設定する機能があり、クライアント ID として有効とみなす URL に制限をかけることができます。この機能を用いれば、「誰でも勝手にクライアント登録できる」という問題を回避できます。

クライアントメタデータを調整する方法がない

2 ヶ月前の 2025 年 10 月に個人ドラフトから IETF WG ドラフトへと昇格したばかりの CIMD 仕様は、現時点では実際に動く実装は限られています。そんな中、Visual Studio Code は CIMD 用のクライアントメタデータを https://vscode.dev/oauth/client-metadata.json で公開しています。

https://vscode.dev/oauth/client-metadata.json (2025年12月15日時点)

{
  "client_name": "Visual Studio Code",
  "grant_types": [
    "authorization_code",
    "refresh_token",
    "urn:ietf:params:oauth:grant-type:device_code"
  ],
  "response_types": [
    "code"
  ],
  "token_endpoint_auth_method": "none",
  "application_type": "native",
  "client_id": "https://vscode.dev/oauth/client-metadata.json",
  "client_uri": "https://vscode.dev/product",
  "redirect_uris": [
    "http://127.0.0.1:33418/",
    "https://vscode.dev/redirect"
  ]
}

上記は 2025 年 12 月 15 日時点の Visual Studio Code のクライアントメタデータですが、これをそのまま登録すると、OpenID Connect Dynamic Client Registration 1.0 仕様 (DCR) に倣う CIMD の実装では、当クライアントの id_token_signed_response_alg プロパティの値に RS256 を設定するでしょう。なぜなら、DCR 仕様で「id_token_signed_response_alg が省略された際のデフォルト値は RS256」と定められているからです。

この結果、そのクライアントに発行される ID トークンの署名のアルゴリズムは RS256 になります。しかし、サーバによってはこのアルゴリズムを使用不可としているため、このままでは「クライアントを登録できたものの ID トークンを発行してもらえない」という問題が起こってしまいます。

FAPI 2.0 Security Profile では PS256、ES256、EdDSA using Ed25519、以外のアルゴリズムを使用不可としています。

しかしながら、クライアントが信頼できる通信相手であるかどうかを確認する方法すら定義していない CIMD 仕様には、当然メタデータを調整する仕組みなど定義されていません。

メタデータポリシー

一方、OpenID Federation 1.0 には、末端エンティティが自身のものだと主張しているメタデータを、トラストチェーンを構成するトラストアンカーや中間権威機関のポリシーに基づいて変更する仕組みが存在します。そのポリシーはメタデータポリシー (Metadata Policy) と呼ばれます。

OpenID Federation 1.0 のメタデータポリシー

例えば次のようなクライアントメタデータがあるとします。

元となるクライアントメタデータ

{
  "client_name": "Example Client",
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code"
  ],
  "token_endpoint_auth_method": "none",
  "client_id": "https://example.com/client.json",
  "redirect_uris": [
    "https://example.com/redirect"
  ]
}

このクライアントメタデータに次のメタデータポリシーを適用すると、

メタデータポリシー

{
  "id_token_signed_response_alg": {
    "default": "ES256",
    "one_of": ["ES256", "ES384", "ES512"]
  },
  "redirect_uris": {
    "add": [
      "http://localhost:12345/redirect"
    ]
  }
}

メタデータポリシーの文法は OpenID Federation 1.0 の Section 6.1. Metadata Policy で定義されています。

結果として次のようなクライアントメタデータが得られます。redirect_uris に http://localhost:12345/redirect が追加され、ES256 という値を持つ id_token_signed_response_alg プロパティが新しく登場していることに注目してください。

メタデータポリシー適用後のクライアントメタデータ

{
  "client_name": "Example Client",
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code"
  ],
  "token_endpoint_auth_method": "none",
  "client_id": "https://example.com/client.json",
  "redirect_uris": [
    "https://example.com/redirect",
    "http://localhost:12345/redirect"
  ],
  "id_token_signed_response_alg": "ES256"
}

CIMDメタデータポリシー

OpenID Federation 1.0 はメタデータを調整する仕組みを定義しました。しかし、後発の CIMD 仕様にはそのような仕組みはありません。そのため、同等の仕組みが欲しければ、認可サーバや OpenID プロバイダは、独自の拡張機能として実装する必要があります。

実装方法は幾つかあるでしょうが、折角 OpenID Federation 1.0 が柔軟なメタデータポリシー文法を定義してくれているので (Section 6.1)、これを活用するのがよいでしょう。

そして、OpenID Federation 1.0 でトラストアンカーや中間権威機関がメタデータポリシーを持つのと同じように、認可サーバにもメタデータポリシーを持たせるのが素直な実装でしょう。

この用途のため、Authlete(オースリート) ではサービスに次のプロパティ群を追加しました。

プロパティ	説明
cimdMetadataPolicyEnabled	CIMD で取得したクライアントメタデータにメタデータポリシーを適用するかどうかを示す真偽値
cimdMetadataPolicy	CIMD で取得したクライアントメタデータに適用するメタデータポリシー

例えばこれらのプロパティ群を次のように設定すると、

CIMD メタデータポリシーの設定

{
  "cimdMetadataPolicyEnabled": true,
  "cimdMetadataPolicy": "{\"id_token_signed_response_alg\":{\"default\":\"ES256\"}}"
}

id_token_signed_response_alg プロパティのデフォルト値を ES256 にすることができます。

CIMD仕様を拡張するべきか

Authlete に CIMD を実装したことを LinkedIn に投稿したところ、大きな反響がありました。世の中が「MCP 仕様に CIMD が採用された」という話題で盛り上がっているところに「CIMD 実装完了」という情報を投げ込んだのでインパクトがありました。

Authlete はバージョン 2.3 で OpenID Federation 1.0 をサポート済みであり、その実装経験があるため、CIMD 仕様単体ではセキュリティ的に商用運用に耐えられないことはすぐに分かりました。そのため、CIMD 実装時に Authlete 独自の補完機能も実装しました。

Authlete 社のウェブサイトで公開されている『OAuth Client ID Metadata Document (CIMD)』を読んで Authlete による補完機能を知った人から次のような質問をもらいました。

Takahiko- Authlete controls you note feel less like optional conveniences and more like the guardrails that make CIMD safe to operationalize at scale..

QQ: do you see CIMD evolving toward a minimal trust model of its own, or remaining intentionally policy driven?

(日本語訳)
Takahiko さん、Authlete による制御機能は、単なるオプション的な便利機能というよりも、CIMD を大規模運用するうえで安全性を担保するためのガードレールのように感じられます。

質問ですが、CIMD は今後、独自のミニマルなトラストモデルへと進化していくとお考えですか？ それとも、意図的にポリシー駆動のままに留められるとお考えですか？

いやー、そうなんですよ。Authlete による便利機能という位置付けにしていますが、CIMD の商用運用を考えたら、同等の機能は必須になるでしょう。

では、そういう機能を取り込むために CIMD 仕様を拡張していくべきかというと、私はそう考えていません。私の回答は下記のとおりです。

Once you start thinking about it seriously, all kinds of considerations pop up — things like trust chains, metadata policies, and metadata choices from OpenID Federation 1.0 and the RP Metadata Choices spec. But if CIMD tried to pull all of that in and keep expanding, it would basically turn into another version of OpenID Federation 1.0. And if that happened, CIMD would lose the whole point of why it exists. So my guess is that CIMD will stay simple.

(日本語訳)
真剣に考え始めると、トラストチェーンやメタデータポリシー、OpenID Federation 1.0 や RP Metadata Choices 仕様にあるメタデータ選択など、さまざまな考慮事項が次々に出てきます。しかし、CIMD がそれらをすべて取り込んで拡張し続けてしまうと、最終的には OpenID Federation 1.0 と同等のものになってしまうでしょう。そうなると、CIMD が存在する意味そのものが失われてしまいます。したがって、CIMD は今後もシンプルなままであり続けるだろう、というのが私の見立てです。

CIMD 仕様策定者は OpenID Federation 1.0 という先行仕様の存在を知っています。それでも CIMD 仕様を新たに策定することにしたのですから、OpenID Federation 1.0 に近付けるような変更を CIMD 仕様に加えるとは考えにくいのです。

おわりに

MCP 仕様が DCR の替わりに CIMD を推奨することにしたため、しばらくの間は CIMD と DCR を比較する記事の投稿が続くでしょう。しかしながら、私は「CIMD と比較すべきは DCR ではなく OpenID Federation 1.0」だと考えています。

その比較により、CIMD に何が足りないのかが分かり、どういう機能を追加実装する必要があるのか分かるからです。本記事で紹介した『CIMD メタデータポリシー』機能も、OpenID Federation 1.0 のメタデータポリシー (Section 6.1) を知っているからこそ設計・実装できた機能です。

イベント告知

2025 年 12 月 19 日に開催予定の『OpenID BizDay #18 ~ AIdentity × Security CollabDay』というイベントで、弊社のメンバーが CIMD のデモを含む『Authlete で実装する MCP OAuth 2.0 認可サーバー』という LT を行います。お楽しみに！