Decouple OAuth issuer and MCP resource URLs for tunnel/proxy deployments

[xiepixie]

Environment & Context

When connecting DevSpace to ChatGPT through OpenAI's official Secure MCP Tunnel, ChatGPT accesses the MCP server through an OpenAI-hosted tunnel resource, while DevSpace's OAuth Authorization Server may remain hosted at a separate public HTTPS origin.

In this setup, the OAuth Authorization Server origin and the externally visible MCP Resource URI are intentionally different.

Problem

DevSpace currently derives both its OAuth Authorization Server configuration and its MCP resource identity from publicBaseUrl.

In SingleUserOAuthProvider (oauth-provider.ts), authorization and token exchange validate the requested OAuth resource using @modelcontextprotocol/sdk's checkResourceAllowed.

The /mcp route in server.ts performs the same resource validation when checking the bearer token.

checkResourceAllowed requires the requested and configured resources to have the same origin.

This works when DevSpace itself is exposed directly at publicBaseUrl, but fails when the externally visible MCP resource is an OpenAI Secure MCP Tunnel endpoint while the OAuth Authorization Server remains at another origin.

For example:

OAuth Authorization Server:
https://devspace.example.com

MCP Resource:
<OpenAI-hosted Secure MCP Tunnel endpoint>

The resulting resource mismatch causes authorization/token exchange failures such as:

Invalid or missing OAuth resource

and subsequent MCP requests may fail with:

401 Unauthorized

This prevents DevSpace's current OAuth implementation from working cleanly with OpenAI Secure MCP Tunnel without modifying the server.

Proposed Solution

Decouple the OAuth Authorization Server URL from the accepted MCP Resource URI(s).

For example, DevSpace could support an explicit configuration such as:

DEVSPACE_PUBLIC_BASE_URL=https://devspace.example.com
DEVSPACE_OAUTH_ALLOWED_RESOURCE_URLS=https://<exact-tunnel-resource>

or equivalent structured configuration.

The existing publicBaseUrl behavior could remain the default for backward compatibility. When additional resource URLs are configured, authorization, token exchange, refresh-token handling, and /mcp bearer-token validation would all validate against the same explicit allowlist.

I would prefer explicit resource URIs rather than trusting broad gateway domains, so OAuth audience/resource binding remains narrowly scoped.

Why this helps

This would support deployments where:

OAuth / browser-facing endpoints
ChatGPT → public HTTPS endpoint → DevSpace OAuth endpoints

High-frequency MCP traffic
ChatGPT → OpenAI Secure MCP Tunnel → tunnel-client → 127.0.0.1 → DevSpace /mcp

The OAuth Authorization Server can remain publicly reachable as required for the browser-facing OAuth flow, while the MCP server itself remains private and high-frequency tool traffic uses Secure MCP Tunnel.

It would also make DevSpace compatible with other reverse-proxy or gateway deployments where the OAuth issuer and externally visible MCP resource intentionally use different origins.

[znbsf]

Thanks for tracking this. We tested DevSpace with OpenAI Secure MCP Tunnel in a local-only setup and can confirm that the OAuth issuer/resource split described here is the key blocker for using DevSpace OAuth directly through the tunnel.

The workaround that worked for us was:

• ChatGPT connector: Tunnel + Unauthenticated / No authentication
• tunnel-client upstream points to a local loopback auth proxy, for example http://127.0.0.1:<proxy-port>/mcp
• the local auth proxy performs DevSpace OAuth on loopback using the owner token, keeps the OAuth token only in process memory, and forwards MCP requests to DevSpace with Authorization: Bearer ...
• DevSpace itself stays bound to 127.0.0.1; no public listener or inbound firewall rule is needed

This avoids making the tunnel endpoint act as the OAuth server while still keeping DevSpace protected locally. A native fix that allows the OAuth issuer/base URL and the accepted MCP resource URL(s) to be configured independently would remove the need for this proxy workaround.

A few operational gotchas from the setup:

1. When DevSpace is behind any proxy layer, DEVSPACE_TRUST_PROXY=1 is important. In a local helper proxy, it is also safer to strip incoming Forwarded / X-Forwarded-* headers before forwarding to DevSpace unless those headers are intentionally part of the deployment.
2. The OpenAI tunnel-client initial MCP probe can show ProbeStatus=timeout even when the real MCP initialize and tool calls work. Endpoint health plus actual DevSpace tool_call logs are stronger readiness signals than the initial probe status alone.
3. On Windows/corporate proxy environments, localhost health checks can accidentally honor HTTP_PROXY / ALL_PROXY and return a false 503 with Proxy-Connection. Local checks should force no-proxy behavior for 127.0.0.1 / localhost, while still allowing the tunnel-client control plane to use the corporate HTTPS proxy if required.

No runtime API key, owner token, or local workspace path should be logged or shared when debugging this path.