はじめに

最近、LLM 界隈では MCP が流行しています。一方で実装にあたっては、機密リソースや操作へのアクセスを保護する必要があります。MCP は便利ですが、データベース操作や管理機能にアクセスできるケースもあるため、認証・認可により、許可されたユーザーのみが MCP にアクセスできるようにすることが重要です。

MCP へのアクセス制御を行う際、クライアントは事前登録された情報（Client ID / Client Secret）を用いてアクセスする方法が一般的です。加えて、DCR（Dynamic Client Registration）を利用し、誰でも認証サーバーにクライアントを登録できるようにする方法もあります。

今回は、レート制限やログ取得は行いたい一方で、アクセス自体はオープンにしたいという要件がありました。事前登録の運用で Client ID と Client Secret を配布する方式は手間がかかるため、実装検討の一環として DCR について調査しました。

DCR(Dynamic Client Registration) とは

最初にも書いた通り、DCR(Dynamic Client Registration) は、OAuth 2.0 クライアントを認可サーバに動的に登録するためのプロトコルです。

RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol

MCPサーバー利用までの全体手順と DCR の役割

アクセスが保護されているMCP サーバが使えるようになるまでに以下のような手順を行います。

Initial Handshake（初期ハンドシェイク：MCP Server は保護されているかなど）
Protected Resource Metadata Discovery（保護リソースのメタデータ発見：認可サーバはどこか・スコープなど）
Authorization Server Discovery（認可サーバの発見）
Client Registration（クライアント登録）
User Authorization（ユーザ認可）
Making Authenticated Requests（認証付きリクエストの）

DCR は 4 のところで行います。

DCR の抽象的なフローについては以下になります。

       +--------(A)- Initial Access Token (OPTIONAL)
        |
        |   +----(B)- Software Statement (OPTIONAL)
        |   |
        v   v
    +-----------+                                      +---------------+
    |           |--(C)- Client Registration Request -->|    Client     |
    | Client or |                                      | Registration  |
    | Developer |<-(D)- Client Information Response ---|   Endpoint    |
    |           |        or Client Error Response      +---------------+
    +-----------+

参考: RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol

(A) Initial Access Token (必須ではない)
(B) Software Statement (必須ではない)
(C) Client Registration Request
(D) Client Information Response or Client Error Response

(A) Initial Access Token (必須ではない)

あとで解説する Client Registration Endpoint へのアクセスを制御するためのトークン
誰でも自由にクライアントを登録するのを防ぐ

(B) Software Statement (必須ではない)

クライアントのメタデータを含む署名付き JWT

(C) Client Registration Request

登録したいクライアントメタデータを送るリクエスト
希望する登録メタデータを（必要ならAのトークン, B の Statement も含めて）呼び出す

(D) Client Information Response or Client Error Response

登録が成功すると、認可サーバは HTTP 201 Created で JSON を返す
ここには最低限 client_id（必須）と、機密クライアントなら client_secret（任意）が入り、さらに発行時刻や secret の期限なども定義

Client Registration Endpoint

下記2点を守っていれば問題ないです。

登録エンドポイントは HTTP POST を受け、リクエストは application/json。さらに TLS必須
成功時レスポンスは HTTP 201 Created + application/json

Requet サンプル

POST /register HTTP/1.1
Host: as.example.com
Content-Type: application/json
Accept: application/json

{
  "client_name": "mcp-cli",
  "redirect_uris": ["https://client.example.com/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "client_secret_basic",
  "scope": "mcp.read mcp.write"
}

201 Responce サンプル

HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "client_id": "s6BhdRkqt3",
  "client_secret": "7Fjfp0ZBr1KtDRbnfVdmIw",
  "client_id_issued_at": 1736123456,
  "client_secret_expires_at": 0,
  "client_name": "mcp-cli",
  "redirect_uris": ["https://client.example.com/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "client_secret_basic",
  "scope": "mcp.read mcp.write"
}

400 Response サンプル

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "error": "invalid_client_metadata",
  "error_description": "redirect_uris is required"
}

401 Response サンプル

HTTP/1.1 401 Unauthorized
Content-Type: application/json
WWW-Authenticate: Bearer error="invalid_token", error_description="Initial access token required"

{
  "error": "invalid_token",
  "error_description": "Initial access token required"
}

おわりに

登録をオープンにするとやはりスパムなどの標的になってしまうので、Initial Access Token などを利用することを検討した方が良いです。

参考

Understanding Authorization in MCP - Model Context Protocol