agentic-community / agentic-community/mcp-gateway-registry
feat: Brokered MCP Server with CIMD Authentication
- 主要言語
- 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 はまだ評価されていません。