こんにちは、R&D部の久米です。

私たちのチームでは日々さまざまな技術に触れていますが、最近「Model Context Protocol (MCP)」というプロトコルの仕様に目を通す機会がありました。

特に自分の関心が高いのは、こうした新しいプロトコルが「どのように認証・認可を扱うか」という点です。セキュリティはシステムの根幹ですし、どのような設計思想に基づいているのかは、技術選定や活用を考える上で非常に重要だと感じています。

そこで今回は、MCPのAuthorizationに関する仕様書を読み込み、その概要と、特に重要だと感じたセキュリティに関する考察をまとめてみることにしました。仕様を深く読み解くというよりは、まずは全体像を掴んで所感をまとめる、というスタンスで進めてみたいと思います。

まず、仕様書を読んで理解した認証フローの全体像です。

大きな特徴として、MCPの認証は OAuth 2.1 をベースに構築されているようです。また、関連するRFC（標準仕様）に厳密に従うことを求めている点が印象的でした。

大まかな流れは以下のようになっていると感じました。

1. サーバーディスカバリー（発見）:
   • クライアントがトークン無しでMCPサーバー（リソースサーバー）にアクセスすると、サーバーは HTTP 401 と WWW-Authenticate ヘッダーを返します。
   • クライアントはこのヘッダーを解析し、リソースサーバーのメタデータ（RFC 9728）を取得しにいきます。
   • そのメタデータに含まれる認証サーバー（Authorization Server）の場所を特定します。
   • 次に、認証サーバーのメタデータ（RFC 8414）を取得し、トークン発行エンドポイントなどの情報を得ます。
2. 動的クライアント登録（推奨）:
   • クライアントは、認証サーバーに対して Dynamic Client Registration (RFC 7591) を使い、自身のクライアントIDなどを動的に登録することが推奨されています。これは、クライアントが事前にすべてのMCPサーバーを知らなくても接続できるようにするためかな、と思います。
3. 認証とトークン取得:
   • クライアントは、PKCE (RFC 7636) を使い、認証コードフローを開始します。
   • この際、後述する resource パラメータ（RFC 8707）を必須で含めます。
   • ユーザーの認可を経て、アクセストークンを取得します。
4. リソースアクセス:
   • 取得したアクセストークンを Authorization: Bearer ヘッダーに含めて、MCPサーバーにリクエストを行います。

仕様書に掲載されていたシーケンス図が分かりやすかったので、引用させていただきます。

コード スニペット

sequenceDiagram
    participant B as User-Agent (Browser)
    participant C as Client
    participant M as MCP Server (Resource Server)
    participant A as Authorization Server

    C->>M: MCP request without token
    M->>C: HTTP 401 Unauthorized with WWW-Authenticate header
    Note over C: Extract resource_metadata URL from WWW-Authenticate

    C->>M: Request Protected Resource Metadata
    M->>C: Return metadata

    Note over C: Parse metadata and extract authorization server(s)<br/>Client determines AS to use

    C->>A: GET /.well-known/oauth-authorization-server
    A->>C: Authorization server metadata response

    alt Dynamic client registration
        C->>A: POST /register
        A->>C: Client Credentials
    end

    Note over C: Generate PKCE parameters<br/>Include resource parameter
    C->>B: Open browser with authorization URL + code_challenge + resource
    B->>A: Authorization request with resource parameter
    Note over A: User authorizes
    A->>B: Redirect to callback with authorization code
    B->>C: Authorization code callback
    C->>A: Token request + code_verifier + resource
    A->>C: Access token (+ refresh token)
    C->>M: MCP request with access token
    M-->>C: MCP response
    Note over C,M: MCP communication continues with valid token

仕様全体を読んでみて、特に「これはセキュリティを強く意識しているな」と感じた点がいくつかありました。

個人的に、これが最も重要なポイントだと感じました。

仕様では、クライアントが認証リクエストおよびトークンリクエストを行う際に、resource パラメータ（RFC 8707）を必須で含めることを要求しています。

これは、クライアントが「どのMCPサーバー（リソース）で使いたいトークンなのか」を認証サーバーに対して明示的に宣言する、ということなのだと思います。

なぜこれが重要かというと、トークンの「Audience（対象者）」を厳密に縛る（バインディングする）ことにつながるからです。

もしこの仕組みがないと、例えば「サービスA」で取得したトークンが、悪意ある攻撃者によって「サービスB」で使われてしまう、といった攻撃（トークンの使い回し）が可能になってしまうかもしれません。

MCPサーバー（リソースサーバー）側も、受け取ったトークンが「自分（のサーバー）向けに発行されたものか」を厳密に検証することが必須とされています。これにより、いわゆる「Confused Deputy Problem（混乱した使節の問題）」や、意図しないリソースへのアクセス権限奪取を防ごうという、強い意志を感じました。

MCPクライアントは、接続先のMCPサーバーや、それに対応する認証サーバーを事前にすべて知っているとは限らない、という前提があるように思いました。

その場合、ユーザーが新しいMCPサーバーに接続しようとするたびに、手動でクライアント登録（クライアントIDの発行など）を行うのは、非常に手間がかかってしまいます。

Dynamic Client Registration (DCR) を推奨することで、クライアントがプログラム的に自己登録できるようになり、ユーザー体験を損なわずにシームレスな連携を実現できる、という狙いがあるのではないでしょうか。

ただし、DCRをサポートしない認証サーバーの場合は、従来通りクライアントIDをハードコードしたり、ユーザーに入力を求めたりする必要がある、とも記載されていました。

その他にも、OAuth 2.1で推奨されているセキュリティ・ベストプラクティスを厳格に要求している点が印象的でした。

• PKCE (RFC 7636) の必須化:
  • パブリッククライアント（ブラウザやモバイルアプリなど）からの認証コード横取り攻撃を防ぐための仕組みで、今や必須のセキュリティ対策だと思います。
• 通信のHTTPS化:
  • 認証サーバーのエンドポイントやリダイレクトURI（localhost を除く）は、すべてHTTPSであることが必須とされています。
• トークンの取り扱い:
  • アクセストークンをURIクエリ文字列に含めることを禁止し、Authorization ヘッダーのみを許可しています。
  • トークンのパススルー（受け取ったトークンをそのまま下流のサービスに流すこと）を明確に禁止しています。

今回は、MCPのAuthorization仕様を読んで、その概要とセキュリティ面での考察をまとめてみました。

全体として、OAuth 2.1や関連RFCのベストプラクティスに厳密に従い、特に Resource Indicators (RFC 8707) によるトークンのAudience縛りを重視することで、非常に堅牢な認証認可の仕組みを構築しようとしていると感じました。

R&Dとしては、こうしたセキュアなプロトコル設計の思想に触れることは、自分たちがシステムを設計する上でも非常に参考になる気がします。

仕様を読んだだけではまだ机上の空論なので、次は実際にこのフローに沿った簡単なMCPクライアントやサーバーのモックを実装してみて、「まず試してみる」ことで、この認証フローの使い勝手やセキュリティ強度を肌で感じてみたいなと思います。