agentic-community / agentic-community/mcp-gateway-registry

feat: Brokered MCP Server with CIMD Authentication

オープン
#1,687 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
Python
スター
911
フォーク
234
平均マージ
1日 11時間
マージ済み PR(30日)
62

説明

### Question: does #988's stance against brokering a downstream MCP server's own OAuth (CIMD) still stand?

## Context

MCP servers that authenticate the real end user via their own IdP using Client ID Metadata Documents (CIMD) — an increasingly common, spec-endorsed pattern (e.g. `@backstage/plugin-mcp-actions-backend` makes CIMD its primary path) — can currently only be onboarded to the registry in catalog mode. None of the egress modes broker a downstream's own IdP (`oauth_user` needs a pre-registered `client_id`/`secret`; `obo_exchange` needs the backend to accept a gateway-minted JWT), and caller auth headers are stripped before any non-internal upstream (`_forward_headers`, #1266), so a client-supplied backend token can't traverse the gateway either.

We found #988, which deliberately declines gateway-brokered downstream-IdP auth ("we'd be running a federated identity service") and designates catalog mode as the pattern for backends with their own IdP.

## The concern (opinion)

For CIMD-authenticated servers, routing them to catalog mode is — in our view — a reduction of the product from (gateway + registry) down to (registry only): discovery still works, but everything the gateway adds on the data path (a single governed endpoint, centralized identity/entitlement enforcement, audit, egress control) is dropped. As CIMD adoption grows, the gateway half of the project quietly stops applying to a growing class of servers — which feels like it undercuts the reason the project is a gateway and not just a registry.

We also note work that looks adjacent to brokering such downstreams: public PKCE egress clients (#1613, merged), client-side DCR on egress (#1519), and publishing the registry's own CIMD document (#992).

## Questions

1. Does the position in #988 still stand as the intended long-term design?
2. Given #1613 / #1519 / #992 moving the gateway toward acting as a dynamic OAuth client to downstreams, is brokering a CIMD (or DCR) downstream on the data path being reconsidered — or are those strictly scoped to other goals?
3. Is catalog mode considered the permanent answer for CIMD-authenticated servers, with the gateway intentionally staying out of their data path?

コントリビューションガイド

コントリビューションガイドを開く

評価

この issue はまだ評価されていません。

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。