MCPの認可仕様に沿ってMCPサーバにアクセスしてみよう

はじめに

前回の第3回では、OAuth 2.1の認可コードフローによるMCPサーバへのアクセス方法について解説しました。第4回となる今回は、まず最新のMCPの認可仕様について確認し、Keycloakを用いてその仕様に沿った認証・認可フローを実装する方法ついて解説します。

MCPの認可仕様

MCPの認可仕様には、MCPクライアントが外部のMCPサーバへ安全にアクセスするための認可の枠組みが定義されています。この認可仕様の概要については第1回で解説しましたが、解説した仕様の次バージョンとなる最新の認可仕様(2025年11月25日版)がリリースされています。

本稿では、第1回で解説した仕様(2025年6月18日版)と11月版の仕様(図1)の違いのうち、特に大きなポイントとなっているクライアント登録方式の変化ついて解説します。

MCPのクライアント登録方式について

最新の認可仕様では、以下の3つのクライアント登録方式がサポートされています。

1. 事前登録
2. Dynamic Client Registration(DCR)
3. Client ID Metadata Documents(CIMD) ※本仕様はドラフト版

なお、これらの登録方式の推奨度は以下のように推移しています。

事前登録

管理者が認可サーバにクライアントの認証情報・リダイレクトURI・認証方法などをあらかじめ手動登録しておく方式です。最新の認可仕様でも有効な方式の1つとして残されているものの、MCPクライアントが増えるほど管理者の登録コストが増え、MCPを取り巻く動的なエコシステムには不向きであり、標準方式にはなり得ないという位置づけになっています。

Dynamic Client Registration (DCR)

RFC 7591に定義されている方式で、認可開始前にクライアントが自分のメタデータを認可サーバにPOSTし、認可サーバがクライアントIDを発行する、という流れを取ります。

6月版ではSHOULD(推奨)という位置づけでしたが、認可サーバのクライアント登録エンドポイントが露出しており攻撃者による大量登録が容易である点や、クライアントメタデータが自己申告でクライアントの信頼性の担保が困難という点から、11月版ではMAY(任意)という位置づけになっています。

Client ID Metadata Documents (CIMD)

11月版からDCRに替わりSHOULD(推奨)の位置づけになっているのがCIMDです(図2)。CIMDではクライアントIDにHTTPS URLを使用します。クライアントはあらかじめ自身のクライアントIDが指すHTTPS URLにクライアントメタデータをJSON形式で公開し、認可サーバはそのURLからメタデータを取得・検証します。

認可サーバは

• クライアントIDがHTTPS URLであること
• そのURLからメタデータを取得できること
• メタデータがJSONオブジェクトであり、各フィールドの型がOAuthの定義に一致していること
• リクエストで渡されたクライアントIDとJSON内のclient_idが完全一致していること

この仕組みによりクライアント登録エンドポイントを露出する必要がなくなり、また「client_id=HTTPS URL」という制約による、クライアントIDのなりすましを対策しています。

KeycloakにおけるCIMD設定

Keycloakは11月版の認可仕様をサポートしており、クライアントポリシー機能を使うことでクライアントの識別にCIMDを使うことができます。

第3回でクライアントポリシーはセキュリティプロファイルを適用するための仕組みとして紹介しました。実際にはこの仕組みはセキュリティ設定に限らず、認可リクエストを受け付ける際のクライアント識別・検証ルールを適用する用途にも利用できます。

KeycoakでCIMDを実現する場合は、

1. 認可リクエストに含まれるclient_idがhttpsのURLであり、かつ許可したドメインに属することをチェックし、
2. そのURLからクライアントメタデータ(JSON)を取得して妥当性を検証する処理をプロファイルに定義し、
3. 条件に合致するリクエストに対してそのプロファイルを適用する
という流れになります。
※本稿では、執筆時点での最新バージョンであるKeycloak 26.6.0を使用します。Keycloakの導入方法については第2回を参考にしてください。
1. CIMDを有効化するオプションを付けて、Keycloakを起動します。

   > bin\kc.bat start-dev --features=cimd

2. 左ペインのRealm Settings→Client policiesタブ→Profilesタブで“Create client profile”をクリックし、CIMD用のクライアントプロファイルを作成します(図3)。
   
3. “Add executor”をクリックし、次のようにExecutorを追加します(図4)。Executor typeでは“client-id-metadata-document”を指定します。続けて、ローカルホストと後述するメタデータの公開先として使用する“hitachi.github.io”をTrusted domainsに指定します。Trusted domainsはクライアントやclient_idが指すメタデータの取得先について、Keycloakがアクセスを許可するドメインの一覧です。この指定がないと認可リクエスト送信時にエラーが発生するため、必須の設定項目です。
   
4. “Add”をクリックしてExecutorをプロファイルに追加し、“Save”をクリックしてプロファイルを保存します。
5. 作成したプロファイルを適用させるためのクライアントポリシーを作成します(図5)。Policiesタブで“Create client policy”をクリックします。
   
   “Save”をクリックしてポリシーを保存します。
6. “Add condition”をクリックし、ポリシーを適用する条件を定義します(図6)。Condition typeでは“client-id-uri”を選択します。ここで「認可リクエストに含まれるクライアントIDが特定のスキームとドメインを含むURIであること」という、CIMDを適用するための条件を設定します。URL schemeには“https”、Trusted domainsには“hitachi.github.io”を入力します。
   
   “Add”をクリックして保存します。
7. “Add client profile”をクリックして、先ほど作成したクライアントプロファイルを指定します(図7)。
   
8. “Add”→“Save”とクリックすればクライアントポリシーの設定は完了です(図8)。
   

以上で、CIMDを使うための設定は完了です。

最後にscopeの設定を行います。今回使用するMCPサーバは“mcp”というscopeを要求するため、“mcp”という名前のscopeを“Optional”で定義しておきます。

左ペインの“Client scopes”→“Create client scope”をクリックして以下のように設定し、“Save”をクリックして保存します(図9)。



これで、Keycloakの設定も完了です。

CIMDによるMCPサーバへのアクセス

それでは、CIMDを使ってMCPサーバへアクセスしてみましょう。今回のハンズオンの構成図を図10に示します。



アクセスするMCPサーバとしてmcp_server_04.pyを用意します。このMCPサーバは第3回と同様にHelloと出力するだけのツールを持つMCPサーバです。

1. 以下のコマンドでサーバを起動し、localhost:3000で動いていることを確認します。

   > uv run mcp_server_04.py
   INFO: Uvicorn running on http://localhost:3000 (Press CTRL+C to quit)

2. こちらも第3回と同様、MCPクライアントとして動作するMCP Inspectorを起動します。以下のコマンドで起動させることができます。

   > npx @modelcontextprotocol/inspector

3. 起動すると自動的にブラウザでMCP Inspectorが開きます(図11)。左ペインのTransport Typeに“Streamable HTTP”を、URLにhttp://localhost:3000/mcpと入力します。
   
4. 左ペインの“Authentication”メニューを開き、“OAuth 2.0 Flow”欄のClient IDに“https://hitachi.github.io/oss-assets/article/thinkit-mcp-auth/04-cimd/mcp-client.json”を入力します。これは本記事のハンズオン用に公開したメタデータのURLで、アクセスすると以下のようなJSONファイルを取得できます。

   {
     "client_id": "://hitachi.github.io/oss-assets/article/thinkit-mcp-auth/04-cimd/mcp-client.json",
     "client_name": "MCP Inspector",
     "application_type": "native",
     "redirect_uris": [
       "http://localhost:6274/oauth/callback",
       "http://127.0.0.1:6274/oauth/callback",
       "http://localhost:6274/oauth/callback/debug",
       "http://127.0.0.1:6274/oauth/callback/debug"
     ],
     "grant_types": [
       "authorization_code"
     ],
     "response_types": [
       "code"
     ],
     "token_endpoint_auth_method": "none",
     "scope": "mcp"
   }

   これを、ローカルで起動したMCP Inspectorのクライアントメタデータとして使用します。
5. MCP Inspectorの設定に戻り、Redirect URLに“http://localhost:6274/oauth/callback”を、Scopeに“mcp”を入力します(図12)。
   
6. それでは、認証フローを実行してみましょう。MCP Inspector右ペイン中央の“Open Auth Settings”をクリックします。この画面でOAuth認証フローをテストできます(図13)。
   
7. 中央の“Quick OAuth Flow”をクリックすると認証フローが開始されます。
   ※“Guided OAuth Flow”メニューからOAuthフローをステップバイステップでテストすることもできます。
8. Keycloakのログイン画面に切り替わるので、登録済みのユーザでログインします(図14)。
   
9. MCP Inspectorにアクセス許可を行います。クライアントIDに指定したURLのホスト名とスコープが表示されていることが分かります(図15)。
   
10. “Yes”をクリックするとアクセストークンの取得が完了し、MCP Inspectorのページに戻ります。画面中央に“Authentication completed successfully”と表示され、MCPサーバにアクセスできるようになります(図16)。
    
11. この状態で左ペインの“Connect”を押すとMCPサーバにアクセスできます。アクセスに成功すると、左ペイン下部に“Connected”と表示されます(図17)。
    
12. 右ペイン上の“Tools”メニューをクリックして“List Tools”→表示された“hello”を選択し、右側の画面で“Run Tool”をクリックすると接続したMCPサーバのツールを実行できます(図18)。
    
13. なお、Keycloakの管理コンソールでClient一覧を確認すると、取得したメタデータ情報が反映されたクライアントが登録されていることが分かります。
    

まとめ

本稿では、最新のMCP認可仕様のうち、認可サーバのクライアントの登録方法にフォーカスして解説しました。また、MCPの最新仕様が要求するCIMDを用いたクライアント識別をKeycloakで実装する方法をハンズオン形式で解説しました。

クライアントの識別にCIMDを用いることで、

• クライアントは自律的にメタデータを公開・更新する
• 認可サーバはポリシーに基づいてクライアントの信頼性を検証する

次回は、Keycloakを用いた、さらに強固なMCPサーバの保護方法について解説します。