メインコンテンツにスキップ

はじめに

互換性のある OAuth 2.1 または OpenID Connect プロバイダーを選択する​

MCP 仕様では、認可 (Authorization) に関していくつかの 特定の要件 があります：

最後の 2 つは必須ではありませんが、最初のものは安全かつ準拠した実装を確保するために必要です。

メモ

新しい MCP ドラフトでは、RFC 8414 が認可サーバー（プロバイダー）に必須となります。新しいドラフトが確定次第、ドキュメントを更新します。

互換性のある MCP プロバイダーリスト で、プロバイダーがサポートされているか確認できます。

MCP Auth SDK をインストールする​

MCP Auth は Python と TypeScript の両方で利用可能です。他の言語やフレームワークのサポートが必要な場合はお知らせください！

pip install mcpauth

または、pipenv や poetry などお好みのパッケージマネージャーを利用できます。

MCP Auth を初期化する​

最初のステップは、プロバイダーの認可サーバーメタデータで MCP Auth インスタンスを初期化することです。プロバイダーが次のいずれかに準拠している場合：

組み込み関数を使ってメタデータを取得し、MCP Auth インスタンスを初期化できます：

from mcpauth import MCPAuth
from mcpauth.config import AuthServerType
from mcpauth.utils import fetch_server_config

mcp_auth = MCPAuth(
    server=fetch_server_config(
      '<auth-server-url>',
      type=AuthServerType.OIDC # または AuthServerType.OAUTH
    )
)

メタデータ URL やエンドポイントを手動で指定する必要がある場合は、他の MCP Auth 初期化方法 をご覧ください。

メタデータエンドポイントをマウントする​

現在の MCP 仕様に準拠するため、MCP Auth は OAuth 2.0 認可サーバーメタデータエンドポイント (/.well-known/oauth-authorization-server) を MCP サーバーにマウントします：

from starlette.applications import Starlette

app = Starlette(routes=[
    mcp_auth.metadata_route(),
])

メタデータ内の URL はそのまま保持されるため、認可サーバーの役割は完全にプロバイダーに委譲されます。/.well-known/oauth-authorization-server にアクセスして MCP サーバーでメタデータエンドポイントをテストできます。

なぜメタデータエンドポイントだけなのか？​

公式 SDK では /authorize や /token などの認可エンドポイントをマウントする認証ルーターが提供されている場合がありますが、私たちがそうしない理由は次の通りです：

  1. メタデータエンドポイントのみをマウントすることで、プロバイダーの機能を最大限活用でき、「車輪の再発明」を避け、MCP サーバーに不要な複雑さを持ち込まずに済みます。
  2. MCP サーバーの役割をリソースサーバーへ移行する 取り組みも進行中であり、OAuth 2.0 保護リソースメタデータ (RFC 9728) が必要となります。つまり、MCP サーバーは 今後は認可ロジックを一切処理せず（メタデータエンドポイントも含む）、プロバイダーに認証 (Authentication) と認可 (Authorization) を委ねるリソースサーバーとしてのみ機能します。
メモ

新しい MCP 仕様が確定次第、MCP Auth も対応予定です。それまでは現行仕様に対応したバージョンをご利用いただけます。

Bearer 認証ミドルウェアを利用する​

MCP Auth インスタンスを初期化したら、Bearer 認証ミドルウェアを適用して MCP ルートを保護できます：

from starlette.applications import Starlette
from starlette.middleware import Middleware
from starlette.routing import Mount
from mcpauth import MCPAuth
from mcp.server.fastmcp import FastMCP

mcp = FastMCP()
mcp_auth = MCPAuth(
  # 認証サーバー設定で初期化
)
bearer_auth = mcp_auth.bearer_auth_middleware(
    "jwt", required_scopes=["read", "write"]
)

app = Starlette(routes=[
    mcp_auth.metadata_route(),
    Mount(
        "/",
        app=mcp.sse_app(),
        middleware=[Middleware(bearer_auth)],
    ),
])

上記の例では、jwt トークンタイプを指定し、read と write のスコープを必須としています。これにより JWT (JSON Web Token) を自動的に検証し、認証済みユーザー情報を含むオブジェクトが生成されます。

情報

JWT (JSON Web Token) について初めて聞いた方もご安心ください。ドキュメント内で必要に応じて説明します。簡単な紹介は Auth Wiki もご覧いただけます。

Bearer 認証の設定について詳しくは、Bearer 認証の設定 をご覧ください。

MCP 実装で認証情報を取得する​

Bearer 認証ミドルウェアを適用すると、MCP 実装内で認証済みユーザー（またはアイデンティティ）の情報にアクセスできます：

Bearer 認証ミドルウェアが適用されると、MCP Auth は認証済みユーザー情報をコンテキスト変数に保存します。MCP ツールハンドラー内で次のようにアクセスできます：

from mcp.server.fastmcp import FastMCP

mcp = FastMCP()
mcp_auth = MCPAuth(
  # 認証サーバー設定で初期化
)

@mcp.tool()
def add(a: int, b: int):
    """
    2 つの数値を加算するツール。
    認証済みユーザー情報はコンテキストで利用可能です。
    """
    auth_info = mcp_auth.auth_info # 現在のコンテキストで認証情報にアクセス
    if auth_info:
        print(f"Authenticated user: {auth_info.claims}")
    return a + b

次のステップ​

引き続き、MCP Auth を MCP サーバーと統合するエンドツーエンドの例や、MCP クライアントでの認証フローの扱い方について学んでいきましょう。