Remote MCPのOAuth discovery: metadata取得先を内部networkから切り離す
Remote MCPの認可では、server由来のmetadata URLをclientが取得します。各discovery段階、DNS解決、redirect、外向き通信を制限し、内部serviceや認証情報への到達を防ぐ受入条件を整理します。
Read in EnglishRemote MCP endpointは、OAuth discoveryの途中でclientが次に接続する場所へ影響できます。MCP公式のsecurity guidanceは、その入力としてWWW-Authenticateのresource_metadata、protected resource metadata内のauthorization server URL、authorization server metadata内の各endpointを挙げています。悪意あるserverがこれらを制御すると、正規のMCP clientがloopback、private network、cloud instance metadataへ接続する経路になり得ます。
守る境界は、設定済みMCP URLだけではありません。discovery中に取得する全URL、redirect先、接続時に実際に使うIP addressまで含みます。最初のURLがHTTPSであることや、hostnameが一度public IPへ解決されたことだけでは、最終到達先を制限できません。
取得chain全体を確認する
| 段階 | 弱い受入証拠 | 有効な受入証拠 |
|---|---|---|
| 最初のchallenge | MCP endpointがHTTPS | resource_metadataを標準URL parserで処理し、外向き通信policyに適合 |
| Metadata展開 | JSONに必要fieldがある | authorization serverと各endpoint URLを個別に再検査 |
| DNS | 検査時にpublic IPへ解決 | 実接続先addressを検査し、DNS変更で禁止rangeへ移れない |
| Redirect | 初回responseが許可先 | 自動redirectを無効化するか、全hopを再検査 |
| Network | applicationにblocklistがある | egress proxyやnetwork policyでもloopback、link-local、private、metadata宛を拒否 |
server上で動く本番clientはHTTPSを必須とし、private、reserved、loopback、link-localの宛先を初期状態で拒否します。IPv6、IPv4-mapped IPv6、別表記の数値IP、redirectも同じpolicyで扱います。開発用例外は、httpやprivate network全体を許可せず、既知のloopback endpointに限定します。
DNSにはtime-of-check/time-of-useの差があります。検査時はpublic IPでも、接続時に内部IPへ変わる名前があります。実際にdialするaddressを確認できる、保守されたSSRF-safe connectorまたはegress gatewayを利用し、redirect後にも同じ判定を適用します。timeout、response size上限、安全なerror処理は探索や応答内容の漏えいを抑えますが、宛先制限の代わりにはなりません。
MCP serverだけでなく実配布clientを確認する
このriskを負うのはOAuth metadataを取得するcomponentです。どのhostやgatewayが取得を行うか、DNS resolverとproxy経路、到達可能なnetworkを記録します。制御された試験では、loopback、private IPv4、link-local、private IPv6、およびpublic test hostから禁止addressへのredirectをmetadataで指定します。禁止先への接続を試みず、失敗応答にも内部response内容が含まれないことを受入条件にします。
公式versioningでは2026-07-28を利用可能なCurrent、/draftを未確定としています。Currentのauthorization security considerationsは、authorization serverがClient ID Metadata Documentを取得する際のSSRFも扱います。これは別のactorにある同種の外向き境界です。どのcomponentがどのURLを取得するかを先に分けて確認します。
確認範囲と限界
ここで扱うのはMCP関連OAuth discoveryとclient metadata取得によるHTTP到達先です。tool実装自身の外向き通信、許可済みpublic endpointの信頼性、付与scopeの適切さは証明しません。allowlist内の宛先も悪意あるmetadataを返せるため、document構造の検証とtokenのMCP resourceへのbindingは別に確認します。