MCPの認証と認可：OAuth 2.1、トークン委譲、そして混乱した代理人問題

認証は、MCPサーバーの強力な機能が正規のユーザーに利用可能か、それとも攻撃者に利用可能かを決定するゲートキーパーです。これを誤ると、他のすべてのセキュリティ制御が無関係になります。メール、ファイル、データベースへのアクセスを持つ認証されていない、または不十分に認証されたMCPサーバーは、他のすべてを十分に堅牢化していても、重大な脆弱性となります。

OWASP GenAIセキュリティプロジェクトのガイドは、認証と認可をMCPサーバーの8つのコアセキュリティドメインの1つとして識別しており、ほとんどの開発者がデフォルトで実装するものを超える特定の要件があります。この投稿では、それらの要件がなぜ存在するのか、そしてそれらを正しく実装する方法を説明します。

MCPにおける認証の課題

MCPサーバーは、複数のプリンシパル間を仲介するため、従来のサービスよりも複雑な認証環境に直面します：

• AIアシスタントを駆動する指示を出すユーザー
• 指示を解釈しツールを呼び出すAIモデル
• MCPクライアント（AIをホストするアプリケーション）
• ツール呼び出しを実行するMCPサーバー
• MCPサーバーがユーザーの代わりに呼び出す下流サービス

これらの関係のそれぞれには、独自の認証と認可制御が必要です。どのリンクの弱点も、他のものをバイパスするために悪用される可能性があります。

必須：リモートサーバー向けOAuth 2.1とOIDC

リモートMCPサーバー（ローカルのSTDIOやUnixソケットではなく、ネットワーク経由でアクセスされるもの）に対して、OWASP GenAIガイドは明確です：OIDCを伴うOAuth 2.1は必須であり、オプションではありません。

この要件が存在する理由は：

OAuth 2.1は明示的なスコープ制御を提供します。 すべてのアクセストークンは、どのリソースとアクションを認可するかを正確に宣言します。MCPサーバーは、ツール呼び出し時に、提示されたトークンがそのアクションに必要な特定のスコープを持っているかどうかを検証できます。ユーザーが認証されているだけでなく、この特定の操作に対して認可されているかどうかを確認します。

OIDCは暗号化されたアイデンティティを提供します。 OpenID Connectは、MCPサーバーがアイデンティティプロバイダーへのラウンドトリップなしで検証できるアイデンティティアサーション（IDトークン）を追加します。サーバーは、すべてのリクエストでiss（発行者）、aud（オーディエンス）、exp（有効期限）、および署名を検証します。

OAuth 2.1トークンは設計上短命です。 最新のOAuth仕様（OAuth 2.0のベストプラクティスを統合し置き換えるもの）は、定期的に更新する必要がある短命アクセストークンを強調しています。これにより、トークンが侵害された場合のダメージウィンドウが制限されます。

すべてのリクエストで検証すべきこと

セッション確立時のみトークンを検証しないでください。すべてのツール呼び出しで検証します：

def validate_token(token: str, required_scope: str) -> TokenClaims:
    claims = jwt.decode(
        token,
        key=get_public_key(claims_preview['kid']),
        algorithms=["RS256", "ES256"]
    )

    assert claims['iss'] == EXPECTED_ISSUER
    assert EXPECTED_AUDIENCE in claims['aud']
    assert claims['exp'] > time.time()
    assert required_scope in claims['scope'].split()

    return claims

リクエスト間で検証結果をキャッシュしないでください。セッション開始時に有効だったトークンが、セッション中に取り消される可能性があります。

動的クライアント環境

MCPクライアントが頻繁に変更される環境（例：異なるAIアシスタントが同じサーバーに接続する）では、静的APIキーや事前共有シークレットは不十分です。OAuth 2.1またはOIDCを使用した動的クライアント登録を使用して、接続時にクライアントのアイデンティティを検証します。特定のクライアントとサーバー間の既知の静的な関係には、許可リスト、ハードコードされた接続ポリシー、または相互TLS（mTLS）が適切です。

ビジネスを成長させる準備はできましたか？

今日から無料トライアルを開始し、数日で結果を確認しましょう。

デモをリクエスト ログイン

混乱した代理人問題

攻撃の理解

混乱した代理人は、MCPアーキテクチャにおいて特に危険な形で現れる古典的な認可脆弱性です。この攻撃は、MCPサーバーが誰の権限で行動しているかの曖昧さを悪用します。

このシナリオを考えてみましょう：

• ユーザーAliceは、限定された権限を持つMCPサーバーに認証されています — 彼女は自分のファイルを読むことができますが、他人のファイルは読めません
• MCPサーバーは、組織内のすべてのファイルを読むための広範なサービスアカウント権限を持っています
• MCPサーバーはトークンパススルーを使用しています：Aliceのトークンを下流サービスに転送します

Aliceがアシスタントに「私のプロジェクトフォルダを要約して」と尋ねると、サーバーはAliceのトークンを使用して彼女のファイルにアクセスします — これは正しい動作です。しかし、攻撃者がサーバーを騙して独自のサービス資格情報を使用してリクエストを行わせた場合（おそらくツールポイズニング攻撃や間接的なプロンプトインジェクションを通じて）、サーバーの昇格された権限を使用して、Aliceが見る権限を持たないファイルにアクセスします。

サーバーは「混乱した代理人」です — その権限を持たない誰かの代わりにその権限を使用するように騙され、権限昇格のプロキシとして機能しています。

なぜトークンパススルーがこの脆弱性を作り出すのか

多くのMCP実装は、簡単のためにクライアントのトークンを下流のAPIに転送します。これは直感的に見えます — ユーザーのトークンはユーザーの権限を表しているため、すべての下流呼び出しにそれを使用することで、正しいアクセス制御が維持されます。

問題：MCPサーバーを信頼された仲介者として認識する下流APIは、転送されたユーザートークンのレベルではなく、サーバーのアイデンティティレベルを使用してリクエストを許可する可能性があります。そして、MCPサーバーが独自のイニシアチブで行動する場合（ユーザーが明示的に要求しなかったAI意思決定を通じて）、ユーザーのトークンではなく独自の資格情報を使用する可能性があります。

ユーザートークンの転送は、以下のことも行います：

• 監査証跡を壊す（下流ログはサーバーのアイデンティティではなくユーザーのアイデンティティを示し、MCP層を不明瞭にする）
• MCPサーバーを侵害した攻撃者に、転送されたすべてのユーザートークンへのアクセスを与える
• 異なるユーザーのトークンが混同されたり再生されたりする可能性がある場合、コンプライアンスの問題を作成する

修正方法：On-Behalf-Ofフローによる明示的なトークン委譲

クライアントトークンを転送する代わりに、MCPサーバーはOAuthの**On-Behalf-Of（OBO）**フローを使用して、下流サービスアクセス用の独自のトークンを取得する必要があります：

ユーザーがMCPクライアントに認証 → クライアントがユーザーアクセストークンを取得
MCPクライアントがMCPサーバーにユーザートークンを提示
MCPサーバーがOBOフローを介してユーザートークンをサーバートークンと交換：
  POST /token
  grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
  assertion=<user_access_token>
  scope=<minimum_required_scope>
MCPサーバーが下流呼び出しに独自のOBOトークンを使用

OBOトークン：

• 特定のツール呼び出しに必要な最小限の権限に明示的にスコープされる
• 呼び出し側としてMCPサーバーを識別する（ユーザーをサブジェクトとして）
• ユーザーの認証イベントに紐付けられる（ユーザーのセッション終了時に取り消すことができる）
• ユーザーの完全なトークンを下流サービスに公開しない

短命でスコープされたトークン

OWASP GenAIガイドは、特定の推奨事項を示しています：時間単位ではなく分単位で測定される有効期間を持つアクセストークンを発行します。 これは、MCPサーバーがクライアントから受け入れるトークンと、下流サービスアクセスのために取得するトークンの両方に適用されます。

なぜ短い有効期間が重要なのか

盗まれたアクセストークンは、正規のユーザーがログアウトしたか、パスワードを変更したか、セッションを取り消したかに関係なく、その完全な有効期間の間有効です。セッションの開始時に盗まれた24時間トークンは、攻撃者に24時間の永続的なアクセスを与えます。セッション中に盗まれた5分間のトークンは、最大5分間を与えます。

短命トークンは、定期的な再認証イベントも強制し、以下の機会を提供します：

• ユーザーのアカウントが停止されたか、権限が変更されたかを再確認する
• 異常な認証パターン（異常な時間、場所、または頻度）を検出する
• 機密操作にステップアップ認証を適用する

トークンスコープの最小化

各トークンは、実行される特定の操作に必要なスコープのみを保持する必要があります。現在のツール呼び出しがread:filesのみを必要とする場合、read:files write:files delete:filesスコープを持つトークンを発行しないでください。これにより、トークンが傍受された場合やモデルが予期しないツール呼び出しに操作された場合のダメージが制限されます。

def get_tool_token(user_id: str, tool_name: str) -> str:
    # ツールを最小限必要なスコープにマッピング
    required_scopes = TOOL_SCOPE_MAP[tool_name]

    return oauth_client.get_token(
        subject=user_id,
        scopes=required_scopes,
        lifetime_seconds=300  # 5分の有効期間
    )

ニュースレターに登録

最新のヒント、トレンド、お得な情報を無料で入手。

メールアドレス

登録する

セッションを状態として扱い、アイデンティティとして扱わない

よくある間違いは、セッションIDを認可プロキシとして使用することです：リクエストが有効なセッションIDを持っている場合、サーバーはそれが認可されていると仮定します。これは、状態管理とアイデンティティ検証を混同しています。

正しいモデル：セッションIDは会話の状態を管理します。認可は、OAuthトークンのクレームを検証することによって、すべてのリクエストで独立して検証されます。有効なセッションIDを持つリクエストであっても、ツール呼び出しが許可される前に、有効で期限切れでない、適切にスコープされたOAuthトークンを提示する必要があります。

これが重要な理由は、セッションIDは、暗号化整合性保証を持つOAuthトークンができない方法で盗まれたり、推測されたり、再生されたりする可能性があるためです。

集中化されたポリシー実施

個々のツールハンドラー全体に散在する認可チェックを実装するのではなく、OWASP GenAIガイドは、以下を行う集中化されたポリシーゲートウェイを推奨しています：

• ツール固有のコードに到達する前に、すべてのツール呼び出しリクエストをインターセプトする
• 認証を検証する（トークン署名、発行者、オーディエンス、有効期限）
• 認可を実施する（この特定のツールに必要なスコープ）
• 同意検証を適用する（ユーザーはこのタイプのアクションを明示的に認可しましたか？）
• ツールフィルタリングを実装する（このツールはこのデプロイメントコンテキストで許可されていますか？）
• 監査のために完全なコンテキストですべての決定をログに記録する

集中化により、ポリシーがすべてのツールとエージェント全体で一貫して適用されることが保証されます。ツール固有の認可チェックは、開発中に忘れられたりバイパスされたりする可能性があります。ゲートウェイチェックはできません。

まとめ：認証チェックリスト

リモートMCPサーバーの最小限の認証セキュリティバーは次のとおりです：

• すべての接続にOAuth 2.1 / OIDCが強制される
• すべてのツール呼び出しでトークン署名、発行者、オーディエンス、および有効期限が検証される
• 下流APIへのトークンパススルーなし — OBOまたはサーバー発行トークンを使用
• ツールごとに最小限必要な権限にスコープされたアクセストークン
• 必須の更新を伴う分単位で測定されるトークン有効期間
• セッションIDは認可プロキシとして使用されない
• 集中化されたポリシー実施ゲートウェイが配置されている
• すべての認証イベントと認可決定が不変的にログに記録される

関連リソース

• MCPサーバーセキュリティ：6つの重大な脆弱性
• MCPセキュリティチェックリスト：安全なデプロイメントのための最小限のバー
• LLM APIセキュリティ：レート制限、認証、および悪用防止
• AIエージェントの保護：マルチステップ攻撃防止
• AIチャットボットセキュリティ監査：何を期待するか