Skip to content

Authorization

Introduction

Purpose and Scope

Model Context Protocol は、transport level における authorization capability を提供し、MCP client が resource owner を代理して制限された MCP server に request を行えるようにします。この仕様は、HTTP-based transport に対する authorization flow を定義します。

Protocol Requirements

authorization は、MCP implementation において任意です (OPTIONAL)。サポートされる場合は、次のとおりです。

  • HTTP-based transport を使用する implementation は、この仕様に準拠するべきです (SHOULD)。
  • STDIO transport を使用する implementation は、この仕様に従うべきではありません (SHOULD NOT)。代わりに environment から credential を取得します。
  • 代替 transport を使用する implementation は、その protocol における確立済みの security best practice に従わなければなりません (MUST)。

Standards Compliance

この authorization mechanism は、以下に挙げる既存の仕様に基づいていますが、単純さを維持しつつ security と interoperability を確保するため、それらの機能のうち選択された一部を実装しています。

  • OAuth 2.1 IETF DRAFT（draft-ietf-oauth-v2-1-13）
  • OAuth 2.0 Authorization Server Metadata（RFC8414）
  • OAuth 2.0 Dynamic Client Registration Protocol（RFC7591）
  • OAuth 2.0 Protected Resource Metadata（RFC9728）
  • OAuth Client ID Metadata Documents（draft-ietf-oauth-client-id-metadata-document-00）

Roles

保護された MCP server は OAuth 2.1 resource server として機能し、access token を用いた protected resource request を受け付け、それに応答できます。

MCP client は OAuth 2.1 client として機能し、resource owner を代理して protected resource request を行います。

authorization server は、必要に応じてユーザーと対話し、MCP server で使用するための access token を発行する責任を持ちます。authorization server の実装詳細は、この仕様の対象外です。resource server と同じ場所でホストされる場合もあれば、別の entity である場合もあります。Authorization Server Discovery section では、MCP server が対応する authorization server の場所を client に示す方法を定めています。

Overview

  1. Authorization server は、confidential client と public client の両方に対して適切な security measure を備えた OAuth 2.1 を実装しなければなりません (MUST)。

  2. Authorization server と MCP client は、OAuth Client ID Metadata Documents をサポートするべきです (SHOULD)。

  3. Authorization server と MCP client は、OAuth 2.0 Dynamic Client Registration Protocol をサポートしてもよいです (MAY)。

  4. MCP server は OAuth 2.0 Protected Resource Metadata（RFC9728）を実装しなければなりません (MUST)。MCP client は authorization server discovery のために OAuth 2.0 Protected Resource Metadata を使用しなければなりません (MUST)。

  5. MCP authorization server は、少なくとも次のいずれか 1 つの discovery mechanism を提供しなければなりません (MUST)。

    • OAuth 2.0 Authorization Server Metadata（RFC8414）
    • OpenID Connect Discovery 1.0

    MCP client は、authorization server と対話するために必要な情報を取得するため、両方の discovery mechanism をサポートしなければなりません (MUST)。

Authorization Server Discovery

この section では、MCP server が関連する authorization server を MCP client に通知する仕組み、および MCP client が authorization server endpoint とサポートされる capability を判断する discovery process を説明します。

Authorization Server Location

MCP server は、authorization server の場所を示すために OAuth 2.0 Protected Resource Metadata（RFC9728）仕様を実装しなければなりません (MUST)。MCP server が返す Protected Resource Metadata document には、少なくとも 1 つの authorization server を含む authorization_servers field が含まれていなければなりません (MUST)。

authorization_servers の具体的な使用方法は、この仕様の対象外です。実装者は、実装の詳細に関する指針として OAuth 2.0 Protected Resource Metadata（RFC9728）を参照すべきです。

実装者は、Protected Resource Metadata document が複数の authorization server を定義できる点に注意すべきです。どの authorization server を使用するかの選択責任は MCP client にあり、RFC9728 Section 7.6 "Authorization Servers" に示されたガイドラインに従います。

Protected Resource Metadata Discovery Requirements

MCP server は、authorization server の場所に関する情報を MCP client に提供するため、以下の discovery mechanism のいずれかを実装しなければなりません (MUST)。

  1. WWW-Authenticate Header: 401 Unauthorized response を返す際、RFC9728 Section 5.1 に記載されているとおり、WWW-Authenticate HTTP header の resource_metadata に resource metadata URL を含めます。

  2. Well-Known URI: RFC9728 で定められた well-known URI に metadata を提供します。これは次のいずれかです。

    • server の MCP endpoint の path に配置する方法: https://example.com/public/mcp の場合、metadata は https://example.com/.well-known/oauth-protected-resource/public/mcp で提供できます
    • root に配置する方法: https://example.com/.well-known/oauth-protected-resource

MCP client は、両方の discovery mechanism をサポートしなければなりません (MUST)。また、解析した WWW-Authenticate header に resource metadata URL が存在する場合はそれを使用し、存在しない場合は、上記の順序で well-known URI を構築して request する方式にフォールバックしなければなりません (MUST)。

MCP server は、resource にアクセスするために必要な scope を示すため、RFC 6750 Section 3 で定義されている scope parameter を WWW-Authenticate header に含めるべきです (SHOULD)。これにより client は、authorization の際に request すべき適切な scope について即座に指針を得られ、least privilege の原則に従い、過剰な permission を request することを防げます。

WWW-Authenticate challenge に含まれる scope は、scopes_supported と一致してもよく、その subset または superset でもよく、あるいは厳密な subset でも superset でもない別の集合でも構いません。client は、challenge された scope set と scopes_supported の間に特定の集合関係があると想定してはなりません (MUST NOT)。client は、現在の request を満たすために、challenge で提供された scope を権威あるものとして扱わなければなりません (MUST)。server は、scope set の構築方法について一貫性を保つよう努めるべきです (SHOULD) が、動的に発行されるすべての scope を scopes_supported に反映する必要はありません。

scope guidance を含む 401 response の例:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

MCP client は、WWW-Authenticate header を解析し、MCP server からの HTTP 401 Unauthorized response に適切に対処できなければなりません (MUST)。

scope parameter が存在しない場合、client は Scope Selection Strategy section で定義された fallback behavior を適用するべきです (SHOULD)。

Authorization Server Metadata Discovery

異なる issuer URL format に対応し、OAuth 2.0 Authorization Server Metadata と OpenID Connect Discovery 1.0 の両仕様との interoperability を確保するため、MCP client は authorization server metadata を discover する際に、複数の well-known endpoint を試みなければなりません (MUST)。

この discovery approach は、OAuth 2.0 Authorization Server Metadata discovery に関する RFC8414 Section 3.1 "Authorization Server Metadata Request" と、OpenID Connect Discovery 1.0 interoperability に関する RFC8414 Section 5 "Compatibility Notes" に基づいています。

path component を持つ issuer URL（例: https://auth.example.com/tenant1）について、client は次の優先順で endpoint を試さなければなりません (MUST)。

  1. path insertion を用いる OAuth 2.0 Authorization Server Metadata: https://auth.example.com/.well-known/oauth-authorization-server/tenant1
  2. path insertion を用いる OpenID Connect Discovery 1.0: https://auth.example.com/.well-known/openid-configuration/tenant1
  3. path appending を用いる OpenID Connect Discovery 1.0: https://auth.example.com/tenant1/.well-known/openid-configuration

path component を持たない issuer URL（例: https://auth.example.com）について、client は次を試さなければなりません (MUST)。

  1. OAuth 2.0 Authorization Server Metadata: https://auth.example.com/.well-known/oauth-authorization-server
  2. OpenID Connect Discovery 1.0: https://auth.example.com/.well-known/openid-configuration

Authorization Server Discovery Sequence Diagram

以下の diagram は、例となる flow を示しています。

sequenceDiagram participant C as Client participant M as MCP Server (Resource Server) participant A as Authorization Server Note over C: Attempt unauthenticated MCP request C->>M: MCP request without token M-->>C: HTTP 401 Unauthorized (may include WWW-Authenticate header) alt Header includes resource_metadata Note over C: Extract resource_metadata URL from header C->>M: GET resource_metadata URI M-->>C: Resource metadata with authorization server URL else No resource_metadata in header Note over C: Fallback to well-known URI probing Note over M: _Not applicable if the MCP server is at the root_ C->>M: GET /.well-known/oauth-protected-resource/mcp alt Sub-path metadata found M-->>C: Resource metadata with authorization server URL else Sub-path not found C->>M: GET /.well-known/oauth-protected-resource alt Root metadata found M-->>C: Resource metadata with authorization server URL else Root metadata not found Note over C: Abort or use pre-configured values end end end Note over C: Validate RS metadata,<br />build AS metadata URL C->>A: GET Authorization server metadata endpoint Note over C,A: Try OAuth 2.0 and OpenID Connect<br/>discovery endpoints in priority order A-->>C: Authorization server metadata Note over C,A: OAuth 2.1 authorization flow happens here C->>A: Token request A-->>C: Access token C->>M: MCP request with access token M-->>C: MCP response Note over C,M: MCP communication continues with valid token

Client Registration Approaches

MCP は、3 つの client registration mechanism をサポートします。シナリオに応じて選択してください。

  • Client ID Metadata Documents: client と server の間に事前の関係がない場合（最も一般的）
  • Pre-registration: client と server の間に既存の関係がある場合
  • Dynamic Client Registration: backwards compatibility または特定の要件のため

すべての option をサポートする client は、次の優先順に従うべきです (SHOULD)。

  1. client がその server 用の pre-registered client information を利用可能であれば、それを使う
  2. Authorization Server がその server がサポートしていることを示している場合は、Client ID Metadata Documents を使う（OAuth Authorization Server Metadata の client_id_metadata_document_supported による）
  3. Authorization Server がサポートしている場合は、fallback として Dynamic Client Registration を使う（OAuth Authorization Server Metadata の registration_endpoint による）
  4. 他に使える option がなければ、client information を入力するようユーザーに促す

Client ID Metadata Documents

MCP client と authorization server は、OAuth Client ID Metadata Document に記載されているとおり、OAuth Client ID Metadata Documents をサポートするべきです (SHOULD)。この approach により、client identifier として HTTPS URL を使用でき、その URL は client metadata を含む JSON document を指します。これにより、server と client の間に事前関係がないという、MCP で一般的なシナリオに対応できます。

Implementation Requirements

Client ID Metadata Documents をサポートする MCP implementation は、OAuth Client ID Metadata Document に記載された要件に従わなければなりません (MUST)。主な要件は次のとおりです。

For MCP Clients:

  • client は、RFC の要件に従った HTTPS URL 上で metadata document をホストしなければなりません (MUST)
  • client_id URL は "https" scheme を使用し、path component を含まなければなりません (MUST)。例: https://example.com/client.json
  • metadata document は、少なくとも次の property を含まなければなりません (MUST): client_id、client_name、redirect_uris
  • client は、metadata 内の client_id value が document URL と完全一致することを保証しなければなりません (MUST)
  • client は、適切な JWKS configuration とともに private_key_jwt を client authentication に使用してもよいです (MAY)。たとえば token endpoint への request においてです。詳細は Client ID Metadata Document Section 6.2 を参照してください

For Authorization Servers:

  • URL 形式の client_id に遭遇したとき、metadata document を取得するべきです (SHOULD)
  • 取得した document の client_id が URL と完全一致することを検証しなければなりません (MUST)
  • HTTP cache header を尊重して metadata を cache するべきです (SHOULD)
  • authorization request で提示された redirect URI を、metadata document にある redirect URI と照合して検証しなければなりません (MUST)
  • document structure が妥当な JSON であり、必須 field を含んでいることを検証しなければなりません (MUST)
  • Client ID Metadata Document Section 6 の security consideration に従うべきです (SHOULD)

Example Metadata Document

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "logo_uri": "https://app.example.com/logo.png",
  "redirect_uris": [
    "http://127.0.0.1:3000/callback",
    "http://localhost:3000/callback"
  ],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

Client ID Metadata Documents Flow

以下の diagram は、Client ID Metadata Documents を使用する場合の完全な flow を示しています。

sequenceDiagram participant User participant Client as MCP Client participant Server as Authorization Server participant Metadata as Metadata Endpoint<br/>(Client's HTTPS URL) participant Resource as MCP Server Note over Client,Metadata: Client hosts metadata at<br/>https://app.example.com/oauth/metadata.json User->>Client: Initiates connection to MCP Server Client->>Server: Authorization Request<br/>client_id=https://app.example.com/oauth/metadata.json<br/>redirect_uri=http://localhost:3000/callback Server->>User: Authentication prompt User->>Server: Provides credentials Note over Server: Authenticates user Note over Server: Detects URL-formatted client_id Server->>Metadata: GET https://app.example.com/oauth/metadata.json Metadata-->>Server: JSON Metadata Document<br/>{client_id, client_name, redirect_uris, ...} Note over Server: Validates:<br/>1. client_id matches URL<br/>2. redirect_uri in allowed list<br/>3. Document structure valid<br/>4. (Optional) Domain allowed via trust policy alt Validation Success Server->>User: Display consent page with client_name User->>Server: Approves access Server->>Client: Authorization code via redirect_uri Client->>Server: Exchange code for token<br/>client_id=https://app.example.com/oauth/metadata.json Server-->>Client: Access token Client->>Resource: MCP requests with access token Resource-->>Client: MCP responses else Validation Failure Server->>User: Error response<br/>error=invalid_client or invalid_request end Note over Server: Cache metadata for future requests<br/>(respecting HTTP cache headers)

Discovery

authorization server は、OAuth Authorization Server metadata に次の property を含めることで、Client ID Metadata Documents を利用する client をサポートしていることを通知します。

{
  "client_id_metadata_document_supported": true
}

MCP client は、この capability を確認するべきであり (SHOULD)、利用できない場合は Dynamic Client Registration または pre-registration にフォールバックしてもよいです (MAY)。

Preregistration

MCP client は、preregistration flow で提供されるような static client credential を利用する option をサポートするべきです (SHOULD)。これは次のいずれかです。

  1. その authorization server とやり取りする際に MCP client が使用するための client ID（必要なら client credential も）を特定用途向けに hardcode する、または
  2. server がホストする configuration interface などを通じてユーザー自身が OAuth client を登録した後、その詳細を入力できる UI をユーザーに提示する

Dynamic Client Registration

MCP client と authorization server は、OAuth 2.0 Dynamic Client Registration Protocol（RFC7591）をサポートしてもよいです (MAY)。これにより、MCP client はユーザー操作なしに OAuth client ID を取得できます。この option は、MCP authorization spec の以前の version との backwards compatibility のために含まれています。

Scope Selection Strategy

authorization flow を実装する際、MCP client は intended operation に必要な scope のみを request することで、least privilege の原則に従うべきです (SHOULD)。初回の authorization handshake において、MCP client は scope 選択について次の優先順に従うべきです (SHOULD)。

  1. 401 response の最初の WWW-Authenticate header に scope parameter がある場合、それを使う
  2. scope が利用できない場合、Protected Resource Metadata document の scopes_supported で定義されたすべての scope を使う。scopes_supported が未定義なら scope parameter は省略する

この approach は、MCP client が通常、個々の scope 選択について十分な判断を行うための domain-specific knowledge を持たないという、general-purpose な性質に対応しています。利用可能なすべての scope を request することで、authorization server と end-user が consent process の中で適切な permission を判断できるようになります。

この approach は、least privilege の原則に従いながら、user friction を最小化します。scopes_supported field は、基本機能に必要な最小限の scope set を表すことを意図しています。追加の scope は、Scope Challenge Handling section に記載された step-up authorization flow を通じて段階的に request されます。

Authorization Flow Steps

完全な Authorization flow は、次のように進行します。

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 Authorization server metadata endpoint Note over C,A: Try OAuth 2.0 and OpenID Connect<br/>discovery endpoints in priority order A-->>C: Authorization server metadata alt Client ID Metadata Documents Note over C: Client uses HTTPS URL as client_id Note over A: Server detects URL-formatted client_id A->>C: Fetch metadata from client_id URL C-->>A: JSON metadata document Note over A: Validate metadata and redirect_uris else Dynamic client registration C->>A: POST /register A->>C: Client Credentials else Pre-registered client Note over C: Use existing client_id end Note over C: Generate PKCE parameters<br/>Include resource parameter<br/>Apply scope selection strategy 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 Parameter Implementation

MCP client は、token を request する対象 resource を明示的に指定するため、RFC 8707 に定義された Resource Indicators for OAuth 2.0 を実装しなければなりません (MUST)。resource parameter については次のとおりです。

  1. authorization request と token request の両方に含めなければなりません (MUST)。
  2. client がその token を使う意図のある MCP server を識別しなければなりません (MUST)。
  3. RFC 8707 Section 2 に定義された MCP server の canonical URI を使用しなければなりません (MUST)。

Canonical Server URI

この仕様において、MCP server の canonical URI は RFC 8707 Section 2 に記載された resource identifier として定義され、RFC 9728 における resource parameter と整合しています。

MCP client は、RFC 8707 の guidance に従い、アクセスしようとする MCP server について、可能な限り最も具体的な URI を提供するべきです (SHOULD)。canonical form は lowercase の scheme と host component を使いますが、robustness と interoperability のため、implementation は uppercase の scheme と host component も受け入れるべきです (SHOULD)。

有効な canonical URI の例:

  • https://mcp.example.com/mcp
  • https://mcp.example.com
  • https://mcp.example.com:8443
  • https://mcp.example.com/server/mcp（個別の MCP server を識別するために path component が必要な場合）

無効な canonical URI の例:

  • mcp.example.com（scheme がない）
  • https://mcp.example.com#fragment（fragment を含む）

Note: https://mcp.example.com/（末尾 slash あり）と https://mcp.example.com（末尾 slash なし）は、RFC 3986 によればどちらも technically valid な absolute URI ですが、specific resource にとって末尾 slash が意味的に重要でない限り、implementation は interoperability を高めるため、一貫して末尾 slash なしの form を使うべきです (SHOULD)。

たとえば https://mcp.example.com にある MCP server にアクセスする場合、authorization request には次が含まれます。

&resource=https%3A%2F%2Fmcp.example.com

MCP client は、authorization server がこの parameter をサポートするかどうかにかかわらず、この parameter を送信しなければなりません (MUST)。

Access Token Usage

Token Requirements

MCP server に request を送る際の Access Token の扱いは、OAuth 2.1 Section 5 "Resource Requests" に定義された要件に準拠しなければなりません (MUST)。具体的には、次のとおりです。

  1. MCP client は、OAuth 2.1 Section 5.1.1 で定義された Authorization request header field を使用しなければなりません (MUST)。
Authorization: Bearer <access-token>

authorization は、同一の logical session の一部であっても、client から server へのすべての HTTP request に含めなければならない点に注意してください (MUST)。

  1. Access Token を URI query string に含めてはなりません (MUST NOT)

request の例:

GET /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Token Handling

OAuth 2.1 resource server としての役割を担う MCP server は、OAuth 2.1 Section 5.2 に記載されたとおりに Access Token を検証しなければなりません (MUST)。MCP server は、RFC 8707 Section 2 に従い、Access Token が intended audience として自分自身向けに発行されたものであることを検証しなければなりません (MUST)。検証に失敗した場合、server は OAuth 2.1 Section 5.3 の error handling 要件に従って response を返さなければなりません (MUST)。無効または期限切れの token には HTTP 401 response を返さなければなりません (MUST)。

MCP client は、MCP server の authorization server によって発行された token 以外を MCP server に送信してはなりません (MUST NOT)。

MCP server は、自身の resource で使用するのに有効な token のみを受け入れなければなりません (MUST)。

MCP server は、その他の token を受け入れたり transit したりしてはなりません (MUST NOT)。

Error Handling

server は、authorization error に対して適切な HTTP status code を返さなければなりません (MUST)。

Status Code Description Usage
401 Unauthorized authorization が必要、または token が無効
403 Forbidden scope が無効、または permission が不足
400 Bad Request 不正な形式の authorization request

Scope Challenge Handling

この section では、client がすでに token を持っているものの、runtime operation 中に追加の permission が必要になった場合の insufficient scope error の扱いを扱います。これは OAuth 2.1 Section 5 で定義された error handling pattern に従い、RFC 9728（OAuth 2.0 Protected Resource Metadata）の metadata field を活用します。

Runtime Insufficient Scope Errors

client が runtime operation 中に scope が不足した Access Token で request を行った場合、server は次の内容で response を返すべきです (SHOULD)。

  • HTTP 403 Forbidden status code（RFC 6750 Section 3.1 に従う）
  • Bearer scheme と追加 parameter を持つ WWW-Authenticate header:
    • error="insufficient_scope" - authorization failure の具体的な種別を示す
    • scope="required_scope1 required_scope2" - operation に必要な最小 scope を示す
    • resource_metadata - Protected Resource Metadata document の URI（401 response との一貫性のため）
    • error_description（任意）- 人が読める error description

Server Scope Management: insufficient scope error を返すとき、server は現在の request を満たすために必要な scope を scope parameter に含めるべきです (SHOULD)。

server は、どの scope を含めるかを柔軟に決定できます。

  • Minimum approach: 特定の operation に対して新たに必要な scope を含めます。すでに許可されている scope も必要なら含め、client が既存の permission を失わないようにします。
  • Recommended approach: 既存の関連 scope と新たに必要な scope の両方を含め、client が以前に許可された permission を失わないようにします
  • Extended approach: 既存の scope、新たに必要な scope、さらに一般に一緒に使われる関連 scope を含めます

どの approach を取るかは、user experience への影響と authorization friction に関する server の判断によります。

server は、client に予測可能な挙動を提供するため、scope inclusion strategy に一貫性を持たせるべきです (SHOULD)。

server は、response に含める scope を決定する際、誤った scope 設定により頻繁なユーザー操作が必要になる可能性があるため、user experience への影響を考慮するべきです (SHOULD)。

insufficient scope response の例:

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="files:read files:write user:profile",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         error_description="Additional file write permission required"

Step-Up Authorization Flow

client は、初回 authorization 時または runtime 中（insufficient_scope）に scope 関連 error を受け取ります。client は、step-up authorization flow を通じて scope を増やした新しい Access Token を request するか、他の適切な方法でそれらの error を処理することで、これらの error に応答するべきです (SHOULD)。ユーザーを代理して動作する client は、step-up authorization flow を試みるべきです (SHOULD)。自分自身の behalf で動作する client（client_credentials client）は、step-up authorization flow を試みてもよいです (MAY)。直ちに request を中止しても構いません。

flow は次のとおりです。

  1. authorization server response または WWW-Authenticate header から error information を解析する
  2. Scope Selection Strategy に従って 必要な scope を判断する
  3. 判断した scope set で （再）authorization を開始する
  4. 新しい authorization を使って 元の request を再試行する。ただし数回までとし、その後は恒久的な authorization failure として扱う

client は retry limit を実装するべきであり (SHOULD)、同じ resource と operation の組み合わせで繰り返し失敗しないよう、scope upgrade attempt を追跡するべきです (SHOULD)。

Security Considerations

implementation は、OAuth 2.1 Section 7 "Security Considerations" に記載された OAuth 2.1 の security best practice に従わなければなりません (MUST)。

Token Audience Binding and Validation

RFC 8707 の Resource Indicators は、Authorization Server がその capability をサポートしている場合、token を intended audience に結び付けることで重要な security benefit をもたらします。現在および将来の採用を可能にするため、次の要件があります。

  • MCP client は、Resource Parameter Implementation section に記載されたとおり、authorization request と token request に resource parameter を含めなければなりません (MUST)
  • MCP server は、自身に提示された token が、自身の利用のために特別に発行されたものであることを検証しなければなりません (MUST)

Security Best Practices document では、token audience validation がなぜ重要なのか、また token passthrough がなぜ明示的に禁止されているのかが説明されています。

Token Theft

client に保存された token、または server 上で cache もしくは log された token を攻撃者が取得すると、resource server に対して正当な request に見える形で protected resource にアクセスできてしまいます。

client と server は、安全な token storage を実装し、OAuth best practice に従わなければなりません (MUST)。詳細は OAuth 2.1 Section 7.1 を参照してください。

authorization server は、漏えいした token の影響を小さくするため、短命な Access Token を発行するべきです (SHOULD)。public client に対しては、OAuth 2.1 Section 4.3.1 "Token Endpoint Extension" に記載のとおり、authorization server は Refresh Token を rotate しなければなりません (MUST)。

Communication Security

implementation は、OAuth 2.1 Section 1.5 "Communication Security" に従わなければなりません (MUST)。

具体的には次のとおりです。

  1. すべての authorization server endpoint は HTTPS 上で提供されなければなりません (MUST)。
  2. すべての redirect URI は、localhost であるか、または HTTPS を使用しなければなりません (MUST)。

Authorization Code Protection

authorization response に含まれる authorization code に攻撃者がアクセスできた場合、その authorization code を使って Access Token と交換しようとしたり、その他の用途に悪用しようとしたりする可能性があります。 （詳細は OAuth 2.1 Section 7.5 を参照してください）

これを軽減するため、MCP client は OAuth 2.1 Section 7.5.2 に従って PKCE を実装しなければならず (MUST)、authorization を進める前に PKCE support を検証しなければなりません (MUST)。PKCE は、verifier-challenge pair を client に作成させることで、元の request を行った者だけが authorization code を token と交換できるようにし、authorization code interception および injection attack を防ぐのに役立ちます。

MCP client は、技術的に可能であれば、OAuth 2.1 Section 4.1.1 で要求されるとおり S256 code challenge method を使用しなければなりません (MUST)。

OAuth 2.1 と PKCE の仕様は、client が PKCE support を discover する mechanism を定義していないため、MCP client は、この capability を検証するために authorization server metadata に依存しなければなりません (MUST)。

  • OAuth 2.0 Authorization Server Metadata: code_challenge_methods_supported が存在しない場合、その authorization server は PKCE をサポートしていないため、MCP client は処理の続行を拒否しなければなりません (MUST)。
  • OpenID Connect Discovery 1.0: OpenID Provider Metadata は code_challenge_methods_supported を定義していませんが、この field は OpenID provider によってよく含まれます。MCP client は、provider metadata response に code_challenge_methods_supported が存在することを検証しなければなりません (MUST)。存在しない場合、MCP client は処理の続行を拒否しなければなりません (MUST)。

OpenID Connect Discovery 1.0 を提供する authorization server は、MCP compatibility を確保するため、metadata に code_challenge_methods_supported を含めなければなりません (MUST)。

Open Redirection

攻撃者は、悪意ある redirect URI を細工して、ユーザーを phishing site へ誘導する可能性があります。

MCP client は、authorization server に redirect URI を登録しておかなければなりません (MUST)。

authorization server は、redirection attack を防ぐため、正確に一致する redirect URI を事前登録済みの値と照合して検証しなければなりません (MUST)。

MCP client は、authorization code flow において state parameter を使用して検証し、元の state が含まれていない結果や一致しない結果を破棄するべきです (SHOULD)。

authorization server は、OAuth 2.1 Section 7.12.2 に示された提案に従い、user agent を信頼されていない URI へ redirect しないよう予防策を講じなければなりません (MUST)。

authorization server は、redirection URI を信頼している場合にのみ、自動的に user agent を redirect するべきです (SHOULD)。URI が信頼できない場合、authorization server はユーザーに情報を提示し、正しい判断をユーザーに委ねても構いません (MAY)。

Client ID Metadata Document Security

Client ID Metadata Documents を実装する際、authorization server は OAuth Client ID Metadata Document Section 6 に詳述された security implication を考慮しなければなりません (MUST)。主な考慮事項は次のとおりです。

Authorization Server Abuse Protection

authorization server は、未知の client から URL を入力として受け取り、その URL を取得します。 悪意ある client はこれを利用して、authorization server に対し、その server がアクセス可能な private administration endpoint など、任意の URL への request を発生させる可能性があります。

metadata document を取得する authorization server は、OAuth Client ID Metadata Document の Server Side Request Forgery（SSRF）Attacks に記載されているとおり、SSRF の risk を考慮するべきです (SHOULD)。

Localhost Redirect URI Risks

Client ID Metadata Documents だけでは、localhost URL impersonation を防げません。攻撃者は、次の方法で任意の client を装うことができます。

  1. 正規 client の metadata URL を自分の client_id として提示する
  2. 任意の localhost port に bind し、その address を redirect_uri として提示する
  3. ユーザーが承認したときの redirect を通じて authorization code を受け取る

server からは正規 client の metadata document が見え、ユーザーには正規 client の名前が表示されるため、攻撃の検出は困難になります。

authorization server は、次を考慮すべきです。

  • localhost のみの redirect URI に対して追加の warning を表示するべきです (SHOULD)
  • security を強化するため、追加の attestation mechanism を要求してもよいです (MAY)
  • authorization 中に redirect URI の hostname を明確に表示しなければなりません (MUST)

Trust Policies

authorization server は、domain-based trust policy を実装してもよいです (MAY)。

  • trusted domain の allowlist（保護された server 向け）
  • 任意の HTTPS client_id を受け入れる（open server 向け）
  • 未知 domain に対する reputation check
  • domain の age や certificate validation に基づく制限
  • phishing 防止のため、CIMD や関連する client hostname を目立つように表示する

server は、自身の access policy を完全に制御します。

Confused Deputy Problem

攻撃者は、third-party API への intermediary として機能する MCP server を悪用し、confused deputy vulnerability を引き起こす可能性があります。盗まれた authorization code を使うことで、ユーザーの同意なしに Access Token を取得できることがあります。

static client ID を使う MCP proxy server は、third-party authorization server に forwarding する前に、動的に登録された各 client についてユーザーの consent を得なければなりません (MUST)（その third-party 側でも追加の consent が必要になる場合があります）。

Access Token Privilege Restriction

MCP server が他の resource 向けに発行された token を受け入れてしまうと、攻撃者が不正 access を得たり、その他の方法で MCP server を侵害したりする可能性があります。

この vulnerability には、重要な 2 つの側面があります。

  1. Audience validation failures. MCP server が、提示された token が自分自身向けであることを検証しない場合（たとえば RFC9068 で言及される audience claim を確認しない場合）、本来は他の service 向けに発行された token を受け入れてしまうことがあります。これは OAuth の基本的な security boundary を破壊し、攻撃者が正当な token を本来の intended service とは異なる service で再利用できるようにしてしまいます。
  2. Token passthrough. MCP server が、誤った audience を持つ token を受け入れるだけでなく、それを変更せず downstream service に forward すると、confused deputy problem を引き起こす可能性があります。つまり downstream API が、その token をあたかも MCP server から来たもののように誤って信頼したり、upstream API によって検証済みだと誤解したりする可能性があります。詳細は Security Best Practices guide の Token Passthrough section を参照してください。

MCP server は、request を処理する前に Access Token を検証し、その Access Token が当該 MCP server 向けに特別に発行されたものであることを確認し、未承認の相手に data が返されないよう必要なあらゆる措置を講じなければなりません (MUST)。

MCP server は、受信した token を検証するために、OAuth 2.1 Section 5.2 の guideline に従わなければなりません (MUST)。

MCP server は、自分自身向けに特別に意図された token のみを受け入れなければならず (MUST)、audience claim に自分自身が含まれていない token、または自分が intended recipient であることを別の方法で確認できない token を拒否しなければなりません (MUST)。詳細は Security Best Practices の Token Passthrough section を参照してください。

MCP server が upstream API に request を送る場合、それらに対しては OAuth client として振る舞う場合があります。このとき upstream API で使う Access Token は別の token であり、upstream authorization server によって発行されたものです。MCP server は、MCP client から受け取った token を passthrough してはなりません (MUST NOT)。

MCP client は、RFC 8707 - Resource Indicators for OAuth 2.0 で定義された resource parameter を実装し使用しなければなりません (MUST)。これにより、token を request する対象 resource を明示的に指定できます。この要件は RFC 9728 Section 7.4 の推奨と整合しています。これにより、Access Token は intended resource に結び付けられ、異なる service 間で悪用されることを防げます。

MCP Authorization Extensions

core protocol に対する authorization extension がいくつかあり、追加の authorization mechanism を定義しています。これらの extension は次の性質を持ちます。

  • Optional - implementation はこれらの extension を採用するか選べる
  • Additive - extension は core protocol の機能を変更したり壊したりせず、新しい capability を追加しつつ core protocol の挙動を維持する
  • Composable - extension は modular であり、衝突せずに一緒に動作するよう設計されているため、implementation は複数の extension を同時に採用できる
  • Versioned independently - extension は core MCP の versioning cycle に従うが、必要に応じて独立した versioning を採用できる

サポートされる extension の一覧は、MCP Authorization Extensions repository で確認できます。