MCPサーバーの保護

Box Community MCPサーバー (セルフホストBox MCPサーバー) は、最初にリリースした際、STDIOトランスポートプロトコル (ローカルのClaude Desktop統合に最適なシンプルな標準入力/標準出力の通信モデル) でのみ動作していました。認証は簡単でした。つまり、MCPサーバーは、ユーザーのBox資格情報を使用してローカル環境で実行されていたため、絶対的な信頼境界線がありました。

しかし、Model Context Protocolエコシステムが進化するにつれて、Boxでは、HTTPトランスポートおよびSSE (Server-Sent Events) トランスポートをサポートする必要性を認識するようになりました。これらのプロトコルにより、共有サービスとして実行されるMCPサーバー、クラウドホスト型エージェント、マルチユーザー展開といった、強力な新しいシナリオが実現します。一方、ネットワーク経由でサーバーに接続しているリモートMCPクライアントをどのように認証するかという、STDIOには存在しなかった重大なセキュリティ上の問題も発生しました。

この問題は、興味深いアーキテクチャの探究へと導き、結果として、MCPクライアントが必要とするOAuth 2.1保護リソースパターン (RFC 9728) の実装に至りました。これにより、BoxのMCPサーバーは、基本的にOAuth 2.1保護リソースを使用することになりました。この結果、セキュリティ境界線、認証パターン、そして複数のOAuthシステムを統合する際に内在する複雑さに関して、興味深い知見が明らかになりました。

この記事では、BoxなどのエンタープライズAPIと統合する安全で柔軟なMCPサーバーを構築する際に直面した課題、下した判断、習得した内容について説明します。

2つの独立した認証レイヤー

HTTPトランスポートとSSEトランスポートを実装する過程で、単一の認証という問題に対処していないことがすぐに明らかになりました。それぞれ目的が異なる2つの異なる認証レイヤーを扱っていたからです。

レイヤー1: MCPクライアント ↔ MCPサーバー認証

質問: 誰がこのリクエストを行っているか

MCPクライアントからHTTPまたはSSE経由でサーバーに接続する場合、以下を確認する必要があります。

これが正規のクライアントかどうか
このリクエストが認証され、承認されているかどうか
このリクエストを処理するべきか、拒否するべきか

これは標準のAPI認証であり、MCPサーバーを不正アクセスから保護します。

レイヤー2: MCPサーバー ↔ Box API認証

質問: どのBoxリソースにアクセスできるか

MCPクライアントを認証した後、サーバーはBox APIと対話する必要があります。

どのBoxユーザーのコンテンツにアクセスする必要があるか
どのような権限があるか
サービスアカウントとして動作しているのか、ユーザーに代わって動作しているのか

これはBox API認証であり、特定のリソースにアクセスするための権限があることをBoxに対して証明します。

0_XUgJV0n0LuMRg6p7

一見すると、この二重認証は不要な複雑さのように思えるかもしれません。なぜ、すべてに1つのOAuthフローを使用できないのでしょうか。その答えは、これら2つの認証レイヤーは、根本的に目的が異なり、異なる信頼境界線に存在することを理解することにあります。

この分離が意図的である理由

この二重認証パターンはバグでも見落としでもありません。これは、開発者に重要な柔軟性を提供するためのアーキテクチャ上の意図的な決定です。これらの認証レイヤーを分離しておくことが実際には1つの機能となっている理由を以下に示します。

柔軟性の力

MCPクライアント認証とBox API認証を切り離すことで、根本的に異なる2つの導入シナリオが実現します。

シナリオ1: 専用のエージェント (サービスアカウント)

財務チームの四半期報告書の作成を支援するAIエージェントを作成していると想像してみてください。このエージェントは、Box内の特定の財務ドキュメントセットへのアクセスを必要としており、どのチームメンバーがエージェントを使用しているかに関係なく、それらのドキュメントのみにアクセスする必要があります。

0_7IQFIJo-Oan62V-e

専用エージェントのMCP認証フロー

サービスアカウントを使用する場合、Box API認証は、MCPクライアントを使用しているユーザーとは無関係です。すべてのユーザーが、慎重に厳選された同じBoxコンテンツにアクセスできます。MCP認証では、エージェントを使用できるユーザーが確認されますが、Box認証では、使用可能なコンテンツが判定されます。つまり、これらはまったく別の問題です。

シナリオ2: パーソナルアシスタント (ユーザーベース)

では、ユーザーが自分のBoxファイルを管理することを支援する汎用AIアシスタントを想像してみてください。各ユーザーは、共有リポジトリではなく、自分のBoxコンテンツにアクセスする必要があります。

0_NuE19T3NWPw7qDpH

パーソナルアシスタントのMCP認証フロー

このシナリオでは、MCPサーバーはMCPクライアントに依存して認証を処理する必要があります。

異なる信頼境界線

これら2つの認証レイヤーは、根本的に異なる信頼境界線に存在します。

MCPクライアント認証: MCPサーバーインフラストラクチャを保護する

「このクライアントが自分のサーバーに接続できるかどうか」
「これは正規のリクエストかどうか」
インフラストラクチャレベルのセキュリティ

Box API認証: Boxコンテンツを保護し、アクセススコープを決定する

「どのBoxリソースにアクセスできるか」
「サービスアカウントとして動作しているのか、ユーザーとして動作しているのか」
データレベルのセキュリティ

企業の柔軟性

この分離により、企業は独自の認証要件を組み込むことも可能になります。

MCPレイヤー: 組織のSSO、OAuthプロバイダ、またはカスタム認証を使用する
Boxレイヤー: Boxアプリの構成に基づいて、Box OAuth、CCG (クライアント資格情報許可)、またはJWTを使用する

たとえば、会社はMCPクライアントに対して独自のドメイン認証を要求する (エージェントへのアクセスを会社の従業員のみに制限する) 一方で、会社のドキュメントへのアクセスを一貫性のある制御されたものにするためにBoxサービスアカウントを使用する場合があります。

シンプルに始める: トークンベースの認証

OAuth 2.1に進む前に、MCPクライアント認証にとって最もシンプルなソリューションであるベアラートークン認証から始めました。

Box API認証は現在も有効で、サポートされているモード (OAuth、CCG、またはJWT) のいずれかを使用しています。

その概念は単純明快です。

シークレットトークン (基本的には強力なパスワード) を生成する
使用環境で設定する: BOX_MCP_SERVER_AUTH_TOKEN=your_secret_token_here
MCPクライアントはこれを承認ヘッダーに含める: Authorization: Bearer your_secret_token_here
MCPサーバーがリクエストの処理前にトークンを検証する

# Simplified middleware concept
class AuthMiddleware:
def __init__(self, app):
self.app = app
self.expected_token = os.getenv("BOX_MCP_SERVER_AUTH_TOKEN")

async def __call__(self, scope, receive, send):
# Extract Authorization header
auth_header = get_header(scope, "authorization")

if not auth_header or not auth_header.startswith("Bearer "):
return unauthorized_response()

token = auth_header.split(" ")[1]

if token != self.expected_token:
return unauthorized_response()

# Token valid, proceed
await self.app(scope, receive, send)

このアプローチは、以下の場合に最適です。

単一ユーザー向けの展開: 1人のユーザーが独自のMCPサーバーを実行
信頼できる環境: 開発、テスト、または社内ネットワーク
シンプルなユースケース: OAuthの複雑さを伴わない簡単な設定
サービス間の通信: クライアントとサーバーの両方を制御する場合

ただし、トークンベースの認証にはいくつかの欠点があります。

ユーザーの識別なし: サーバーはリクエストが認証済みであることを認識しているが、ユーザーが誰であるかは認識していない
シークレットの共有: 複数のユーザーがアクセスを必要とする場合、全員が同じトークンを使用する
手動でのトークン管理: トークンは手動で生成、配布、ローテーションする必要がある
標準的な検出なし: クライアントは認証方法を認識するために帯域外の構成が必要になる

OAuth 2.1の相違

MCPエコシステムをより広く導入することについて検討する中で、MCP仕様をすべて実装するMCPクライアントは、OAuth 2.1標準 (RFC 9728 — OAuth保護リソースメタデータ) を使用して認証要件を自動的に検出することを期待するだろうと気付きました。

標準に準拠したMCPクライアントでは、以下の手順を実行できるはずです。

/.well-known/oauth-protected-resourceにクエリを実行して認証要件を検出する
指定された承認サーバーからトークンを取得する
そのトークンを使用してMCPサーバーにアクセスする

シンプルなトークン認証は動作しますが、この検出メカニズムをサポートしていませんでした。このことがきっかけで、トークン認証を置き換えるのではなく、OAuth 2.1の仕様全体に準拠するMCPクライアントをサポートするために、OAuth 2.0保護リソースエンドポイントを実装することになりました。

MCP OAuth 2.1とBox APIの実装

標準ベースのOAuth 2.1認証がMCPサーバーで機能することを証明するには、サーバー側の保護リソースエンドポイントを実装し、実際の承認サーバーでテストする必要がありました。

RFC 9728 (OAuth 2.0保護リソースメタデータ) に従って、MCPクライアントに必要な検出エンドポイントを実装しました。

# Simplified OAuth 2.1 Protected Resource Metadata endpoint
{
    "authorization_servers": [
        "https://account.box.com"
    ],
    "bearer_methods_supported": [
        "header"
    ],
    "resource": "http://my.host.local:8005/mcp",
    "resource_documentation": "https://developer.box.com/",
    "scopes_supported": [
        "root_readwrite",
        "ai.readwrite"
    ]
}

このエンドポイントでは、MCPクライアントに以下を指定します。

トークンの取得場所: 承認サーバーのURL
トークンの送信方法: 承認ヘッダー経由
このサーバーの情報: 保護されたMCPリソース

次に、MCPクライアントは、承認サーバーにクエリを実行して、特定のOAuth実装に関する詳細情報を取得します。

# https://account.box.com/.well-known/oauth-authorization-server
{
  "issuer": "https://api.box.com",
  "authorization_endpoint": "https://account.box.com/api/oauth2/authorize",
  "token_endpoint": "https://api.box.com/oauth2/token",
  "response_types_supported": [
    "code"
  ],
  "grant_types_supported": [
    "authorization_code",
    "refresh_token"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "revocation_endpoint": "https://api.box.com/oauth2/revoke",
  "revocation_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "code_challenge_methods_supported": [
    "S256"
  ],
  "service_documentation": "https://developer.box.com/guides/authentication/",
  "op_policy_uri": "https://www.box.com/legal/termsofservice",
  "op_tos_uri": "https://www.box.com/legal/termsofservice"
}

これで、MCPクライアントには、OAuth承認フローを開始するために必要なものがすべて揃いました。

OAuth 2.1を使用したテスト

MCPインスペクタを使用してこれをテストする際は、リモートMCPサーバーを構成し、クライアントIDとクライアントシークレットを設定します。

0_rWmeO1jEebkh5R34

特定のクライアントIDとクライアントシークレットを使用して接続するMCPインスペクタ

うまくいきました。MCPクライアントにOAuth 2.1フローを実装すると、サーバーは以下の処理を正常に実行します。

検出エンドポイントを介して認証要件を公開する
最初のOAuth承認フローを実行する
資格情報を内部に保存する

RFC 9728の実装により、MCPサーバーは、より広範なOAuth 2.1エコシステムと互換性を確保しました。OAuth 2.1の検出フローを実装し、クライアントとシークレットの設定方法を提供する任意のMCPクライアントは、サーバーで認証できるようになりました。

DCRへの対処

Box APIは、動的クライアント登録 (DCR) をサポートしていません。

すべてのMCPクライアントが同じように動作するわけではなく、同じ会社のクライアントであっても動作が異なる場合があります。例えば、Claude DesktopではクライアントIDとクライアントシークレットの設定をサポートしていますが、Claude Codeではサポートしておらず、DCRが必要になります。

これを機能させるには、以下を実行する必要があります。

Boxの承認サーバーのメタデータに登録エンドポイントを追加する
Box APIの適用で指定されたクライアントIDとクライアントシークレットを常に返す独自の登録エンドポイントを作成する

1つ目は比較的簡単です。Boxの承認エンドポイントを独自のエンドポイントに置き換えます。

{
  "resource": "http://my.host.local:8005/mcp",
  "authorization_servers": [
    "http://my.host.local:8005"
  ],
  "scopes_supported": [
    "root_readwrite",
    "ai.readwrite"
  ],
  "bearer_methods_supported": [
    "header"
  ],
  "resource_documentation": "https://developer.box.com/"
}

http://my.host.local:8005/.well-known/oauth-authorization-serveエンドポイントの実装では、元の https://account.box.com/.well-known/oauth-authorization-serverにクエリを実行し、登録エンドポイントが存在しない場合に、独自のエンドポイントを挿入します。

{
  "issuer": "https://api.box.com",
  "authorization_endpoint": "https://account.box.com/api/oauth2/authorize",
  "token_endpoint": "https://api.box.com/oauth2/token",
----------------------------------------------------------------------
  "registration_endpoint": "http://my.host.local:8005/oauth/register",
----------------------------------------------------------------------
  "scopes_supported": [
    "root_readwrite",
    "ai.readwrite"
  ],
  "response_types_supported": [
    "code"
  ],
  "grant_types_supported": [
    "authorization_code",
    "refresh_token"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "service_documentation": "https://developer.box.com/guides/authentication/",
  "revocation_endpoint": "https://api.box.com/oauth2/revoke",
  "revocation_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "code_challenge_methods_supported": [
    "S256"
  ],
  "op_policy_uri": "https://www.box.com/legal/termsofservice",
  "op_tos_uri": "https://www.box.com/legal/termsofservice"
}

MCPクライアントがそのエンドポイントに到達すると、次のペイロードが送信されます。

{
  "redirect_uris": [
    "http://localhost:6274/oauth/callback/debug"
  ],
  "token_endpoint_auth_method": "none",
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code"
  ],
  "client_name": "MCP Inspector",
  "client_uri": "https://github.com/modelcontextprotocol/inspector",
  "scope": "root_readwrite ai.readwrite"
}

あとは、特定のクライアントIDとクライアントシークレットを送り返すだけです。

{
  "redirect_uris": [
    "http://localhost:6274/oauth/callback/debug"
  ],
  "token_endpoint_auth_method": "none",
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code"
  ],
  "client_id": "...",
  "client_secret": "...",
  "client_id_issued_at": 1762277599,
  "client_secret_expires_at": 0
}

ここからの承認フローは前と同じです。

ただし、これは部分的な実装にすぎません。アプリに事前登録されていないコールバックURIをMCPクライアントが送信した場合、Boxはそれを拒否します。

以下は、MCPクライアント向けの一般的なURIが設定されているBoxアプリケーションの構成です。

0_4rQeJKFNb1tcOLWc

一般的なリダイレクトURI

現在の状態

今回のBox Community MCPサーバーのリリースにより、認証の柔軟性が大幅に向上し、結果としてさまざまなユースケースに対応できるようになりました。

usage: mcp_server_box.py [-h] [--transport {stdio,sse,http}] [--host HOST]
                         [--port PORT]
                         [--mcp-auth-type {oauth,token,none}]
                         [--box-auth-type {oauth,ccg,jwt,mcp_client}]

Box Community MCP Server

options:
  -h, --help            show this help message and exit
  --transport {stdio,sse,http}
                        Transport type (default: stdio)
  --host HOST           Host for SSE/HTTP transport (default: localhost)
  --port PORT           Port for SSE/HTTP transport (default: 8005)
  --mcp-auth-type {oauth,token,none}
                        Authentication type for MCP server (default:
                        token)
  --box-auth-type {oauth,ccg,jwt,mcp_client}
                        Authentication type for Box API (default: oauth)

MCPの認証タイプ

OAuthの場合は、MCPクライアントのOAuthプロトコルを使用し、部分的な動的クライアント登録を実装することで、認証の設定プロセスを簡素化します。この方法では、MCPクライアントで設定されている特定のクライアントIDとクライアントシークレットの資格情報を使用できるため、--box-auth-type=mcp_clientとともに使用する必要があります。この構成により、Boxの認証はMCPクライアントに委任され、MCPクライアントがMCPサーバーに代わってOAuthフローと資格情報の管理に対応することになります。

Tokenの場合は、MCPサーバーが受信したリクエストに対して検証するアクセストークンを設定することで、MCPサーバーにAPIキー方式の認証を提供します。この認証方法は、Box API認証とは関係なく動作し、サーバー側でのoauth、ccg、またはjwtによるBox認証を必要とします。トークン認証は、 --box-auth-type=mcp_clientと併用できません。これは、サーバーがBox認証をクライアントに委任するのではなく、直接処理する必要があるためです。

Noneの場合は、MCPクライアントからのリクエストはすべて有効であるという想定で、MCPクライアントとサーバー間の認証は確認されません。この認証方法は、Box API認証とは関係なく動作し、oauth、ccg、jwt、mcp_clientなど、Boxの認証タイプすべてとシームレスに連携します。stdioトランスポートは自動的にnone認証の使用を強制するため、標準入力/標準出力の通信チャネルではデフォルトの選択肢になることに注意してください。

Boxの認証タイプ

Box APIには常に認証が必要です。MCPサーバーは、複数のBox認証方法をサポートしています。

Box OAuth 2.0は、ユーザーの承認のためにブラウザを開くことで、標準的なユーザー認証を提供します。システムは、セッション全体を通じてユーザーのBoxセキュリティコンテキストを維持し、Box OAuthのクライアントIDとクライアントシークレットの両方を適切に設定することを要求します。

Box CCGは、CCGを有効にしたBoxカスタムアプリを必要とするサーバー側の認証を提供します。この方法では、サービスアカウントまたは特定のユーザーとして認証が行われ、Box管理者がアプリケーションを有効にする必要があります。これは、直接的なユーザーの操作を必要としない、サービスアカウントのシナリオをサポートします。

Box JWT認証は、JSONウェブトークンを使用したサーバー側の認証を提供し、公開キーと秘密キーのペアを持つBox JWTアプリを必要とします。これも、直接的なユーザーの操作を必要としない、サービスアカウントのシナリオをサポートします。

MCPクライアント認証では、Boxの認証をMCPクライアントに委任します。mcp-auth-type=oauthを使用する場合は、MCPクライアントがMCP OAuthフロー中にBox OAuthを構成しますが、mcp-auth-type=noneを使用する場合は、MCPクライアントが承認ヘッダーで有効なBox APIベアラートークンを送信する必要があります。このアプローチは、MCPクライアントが開発者トークン、OAuth、CCG、JWTなど、サポートされている任意の方法でBox承認を処理する場合に役立ちます。

互換性のマトリックス

MCPの認証タイプ: OAuth

Boxの認証タイプ: OAuth -> ❌ サポート対象外
Boxの認証タイプ: CCG -> ❌ サポート対象外
Boxの認証タイプ: JWT -> ❌ サポート対象外
Boxの認証タイプ: MCP_Client -> ✅ サポート対象
Claude Desktopに推奨。MCPクライアントでのクライアントIDおよびクライアントシークレットの設定の送信をサポート。動的クライアント登録を部分的にサポート。

MCPの認証タイプ: Token

Boxの認証タイプ: OAuth -> ✅ サポート対象
Boxの認証タイプ: CCG -> ✅ サポート対象
Boxの認証タイプ: JWT -> ✅ サポート対象
Boxの認証タイプ: MCP_Client -> ❌ サポート対象外
トークンにはサーバー側のBox認証が必要

MCPの認証タイプ: None

Boxの認証タイプ: OAuth -> ✅ サポート対象
Boxの認証タイプ: CCG -> ✅ サポート対象
開発で一般的
Boxの認証タイプ: JWT -> ✅ サポート対象
開発で一般的
Boxの認証タイプ: MCP Client -> ✅ サポート対象
有効なBox APIベアラートークンを承認ヘッダーで送信する必要あり

複雑なシナリオ

単一のユーザーやサーバーの設定を超えた拡張

基本的なMCPサーバー構成は、1台のサーバーを使用する個人開発者には適していますが、会社が複数ユーザーおよび複数のMCPサーバーのシナリオを運用する必要が生じた場合、複雑なシナリオが発生します。

このような企業環境では、1人のユーザーが1台のサーバーに接続するだけにとどまりません。そうではなく、複数のMCPサーバーへの同時アクセスを必要とするユーザーが複数いて、それぞれが異なる権限や認証資格情報を必要としている可能性があります。

ユーザーとサーバーのペアごとに個別に資格情報を構成する必要がある場合、この複雑に絡み合った接続の管理はすぐに手に負えなくなります。そこで、認証プロキシのようなアーキテクチャパターンが必要となります。

認証プロキシは、資格情報の管理、トークンのローテーション、アクセス制御を一元的に処理できる別のサービスに認証を抽出するというソリューションを提供します。これにより、プロキシがインフラストラクチャ内のすべてのユーザーとサーバーのセキュリティ層を処理する間、MCPサーバーはコア機能に集中できます。

0_qGvSdlP43rzbn6_e

認証プロキシのシナリオ

長所:

資格情報の一元管理: 認証資格情報を個々のユーザー構成に分散させるのではなく、すべてを1か所に保存して管理することで、資格情報が分散するリスクが軽減し、更新の展開が容易になります。
シンプルなユーザーエクスペリエンス: ユーザーは、自身がアクセスするMCPサーバーごとに資格情報を構成または管理する必要がありません。プロキシが認証を透過的に処理するため、オンボーディングが迅速化され、サポートの負担が軽減されます。
一貫性のあるアクセス制御: 一元的な場所からすべてのMCPサーバーに対して統一された承認ポリシーを適用し、権限の変更がインフラストラクチャ全体に即座に反映されるようにします。

短所:

単一障害点: 認証プロキシがダウンすると、すべてのユーザーはすべてのMCPサーバーにアクセスできなくなるため、高可用性アーキテクチャと冗長性が重要になりますが、実装はより複雑になります。
レイテンシの増大: すべてのリクエストは認証のために追加のネットワークホップを通過する必要があります。これにより、特に頻度の高い操作や地理的に分散したチームでは、顕著な遅延が生じる可能性があります。
インフラストラクチャの複雑さの増大: 追加のサービスレイヤーの導入、保守、セキュリティ保護が必要になります。これには、負荷分散、フェイルオーバー、ディザスタリカバリに関する考慮事項が含まれます。

まとめ

BoxのようなエンタープライズAPIと統合する安全なMCPサーバーを構築すると、認証がシンプルなことは稀であり、多くの場合はその複雑さに意味があるという重要な事実が明らかになります。

今回学習した内容

Box MCPサーバーにHTTPトランスポートとSSEトランスポートを実装することで、二重認証はバグではなく、重要な柔軟性を提供する1つの機能であることがわかりました。

MCPクライアント認証は「サーバーを呼び出しているユーザー」を答えることで、インフラストラクチャを保護します。
Box API認証は「アクセス可能なコンテンツ」を答えることで、操作の範囲を決定します。

この2つは異なる目的を果たし、異なる信頼境界線に存在します。また、厳選されたコンテンツを使用する専用エージェント (サービスアカウント) から、ユーザーのファイルにアクセスするパーソナルアシスタント (ユーザーごとのOAuth) まで、さまざまな展開パターンを可能にします。

今回構築したもの

今回の実装では、標準ベースの認証が機能することを実証しています。

✅OAuth 2.1保護リソースエンドポイント (RFC 9728) により、標準に準拠したMCPクライアントの検出が可能になります。
✅ 柔軟な認証モードにより、シンプルなベアラートークンからOAuth 2.1のフロー全体まで、すべてがサポートされます。
✅ 実績のあるBox API統合は、OAuth、CCG、およびJWTの認証方法に対応しています。

今後の方向性

マルチユーザー展開では、MCPサーバー内に組み込まれたトークン管理により、複数のユーザーが各自のBoxコンテンツにアクセスすることをサポートするために必要なトークンマッピング、ストレージ、Box OAuthオンボーディングフローが追加されます。このアプローチは、展開をシンプルに保ちながら、大半のユースケースに対応します。

より複雑な要件 (複数のMCPサーバー、一元化された認証、マルチバックエンドのサポート) を持つ組織にとって、認証プロキシパターンは、検討する価値のある興味深い代替手段となります。このアプローチは「正しい」答えとしてではなく、特定のシナリオに有効なアーキテクチャ上の選択肢として記録済みです。

大局的な見地

Box MCPサーバーで直面した課題は、Boxに固有のものではありません。エンタープライズAPIと統合するいずれのMCPサーバーでも、以下のように同様の課題に直面することになります。

MCPクライアントの認証方法
認証済みユーザーをバックエンドの資格情報にマッピングする方法
トークン管理ロジックの配置場所
シンプルさと柔軟性のバランスの取り方

普遍的な「正しい」答えはありません。答えは、展開モデル、規模、セキュリティ要件、組織構造によって異なるためです。

ご参加ください

Box MCPサーバーはオープンソースのため、これらの認証パターンは、コミュニティからの意見と実験によって改善されると考えています。以下に該当する方がいれば、ぜひご意見をお聞かせください。

トークンの管理方法を改善するためのアイデアがある
認証プロキシのプロトタイプを作成したい
独自のMCPサーバーで同様の問題を解決しようとしている
アーキテクチャについて質問がある

BoxのGitHubリポジトリにアクセスし、Issueを作成したり、プルリクエストを送信したり、MCPエコシステムの認証パターンに関するディスカッションを始めたりできます。

安全で柔軟なAIエージェントインフラストラクチャの構築は、チームで行うことが重要です。一緒に考えていきましょう。