MCPRemoteProxy should not require authentication

[danbarr]

Currently, the MCPRemoteProxy resource requires oidcConfig for front-end authentication. This creates two problems:

1. Inconsistency with MCPServer: oidcConfig is optional on MCPServer but required on MCPRemoteProxy
2. Blocks legitimate use cases:
   • vMCP scenarios: When a vMCP server handles frontend authentication, the backend MCPRemoteProxy shouldn't require its own auth
   • Public remote MCPs: Many public remote MCP servers require no authentication (e.g., context7-remote, mermaid, mcp-spec, toolhive-doc-mcp-remote). Enterprises may want to use these while still collecting telemetry or controlling network egress points, but can't deploy them without configuring unnecessary OIDC

Current behavior: MCPRemoteProxy requires oidcConfig to be specified, blocking deployment of unauthenticated remote proxies.

Expected behavior: oidcConfig should be optional on MCPRemoteProxy, allowing:

• Deployment of public/unauthenticated remote MCPs
• Backend proxies in vMCP configurations where auth is handled at the vMCP layer
• Enterprise use cases for telemetry collection and egress control without authentication requirements

It's technically possible to create an MCPRemoteProxy resource with oidcConfig: {}, but in this case it defaults to trying to configure Kubernetes authentication, and this generally fails because the internal cluster certificate isn't trusted.

Suggested fix: Make oidcConfig optional on MCPRemoteProxy CRD, matching the behavior of MCPServer.

[juancarlosm]

Same problem here.

Exmaple for deepwiki:

apiVersion: toolhive.stacklok.dev/v1alpha1
kind: MCPRemoteProxy
metadata:
  name: deepwiki-rproxy
spec:
  groupRef: dev
  remoteURL: https://mcp.deepwiki.com/mcp
  transport: streamable-http
  telemetry:
    prometheus:
      enabled: true

Returns: spec.oidcConfig: Required value

[JAORMX]

So, I'm not sure about this. If you don't have authentication in an MCPRemoteProxy, you would not get any auditing. nor a lot of the advantages that come with it. In cases of MCP servers that don't require auth you'd get telemetry... but that's it.

So.... why would you need a remote proxy then? wouldn't you then just go directly to the remote MCP?

[danbarr]

Collecting usage telemetry is one reason, another would be I want to put them behind a vMCP endpoint for aggregation or a composite workflow, and currently that's not possible to do with a remote MCP that doesn't use authentication.

[ChrisJBurns]

This issue has been resolved by the introduction of the MCPOIDCConfig shared resource and the deprecation of the inline oidcConfig field. Both OIDC fields on MCPRemoteProxy are now fully optional — you can deploy an MCPRemoteProxy with no authentication at all.

Evidence

CRD definition — both fields are pointer types marked +optional with omitempty, and the only CEL rule enforces mutual exclusivity (not "at least one required"):

• mcpremoteproxy_types.go L64-72

Controller handles nil OIDC config cleanly at every layer:

• Validation returns nil immediately when no OIDC config is set: mcpremoteproxy_controller.go L458-460
• handleOIDCConfig removes the condition when OIDCConfigRef is nil: mcpremoteproxy_controller.go L944-946
• Legacy fallback path returns (nil, nil) for nil config, adding no OIDC options: controllerutil/oidc.go L28-34
• OIDC resolver returns (nil, nil) when GetOIDCConfig() is nil: oidc/resolver.go L92-94

Key PRs:

• Add MCPOIDCConfig CRD types and MCPServer reference field #4461 — Added MCPOIDCConfig CRD types and oidcConfigRef field on MCPServer
• Wire MCPOIDCConfig into MCPRemoteProxy controller #4509 — Wired MCPOIDCConfig into MCPRemoteProxy controller (deprecated inline oidcConfig, added oidcConfigRef, both optional)
• Wire MCPOIDCConfig into VirtualMCPServer controller #4493 — Wired MCPOIDCConfig into VirtualMCPServer controller

All three use cases from this issue now work:

1. Public/unauthenticated remote MCPs — deploy with neither OIDC field set
2. Backend proxies behind vMCP — auth handled at the vMCP layer, backend MCPRemoteProxy needs no auth
3. Enterprise telemetry/egress control — proxy without authentication requirements

Closing as resolved.