OAuth endpoints (/oauth/authorize and /oauth/token) are not accessible through Secure MCP Tunnel

[xlingsy]

Summary

I'm trying to expose coding-tools-mcp through the OpenAI Secure MCP Tunnel and use it with ChatGPT Connector using OAuth 2.1 (Authorization Code + PKCE).

The MCP endpoint works correctly, but OAuth cannot complete because the OAuth endpoints exposed in the discovery metadata are not reachable through the tunnel.

I'm not sure whether this is expected behavior or a bug.

Environment

• tunnel-client: v0.0.9
• coding-tools-mcp: v0.1.7

Reproduction

Start coding-tools-mcp:

export CODING_TOOLS_MCP_AUTH_MODE=oauth
export CODING_TOOLS_MCP_SERVER_URL=https://api.openai.com/v1/tunnel/<tunnel-id>/mcp

coding-tools-mcp \
  --workspace ./ \
  --tool-profile full

Start tunnel-client:

tunnel-client run \
  --control-plane.api-key env:OPENAI_API_KEY \
  --control-plane.tunnel-id <tunnel-id> \
  --mcp.server-url http://127.0.0.1:8000/mcp

Configure a ChatGPT Connector using OAuth.

Local OAuth discovery

Locally everything works:

curl http://127.0.0.1:8000/.well-known/oauth-authorization-server

returns

{
  "issuer": "https://api.openai.com/v1/tunnel/<tunnel-id>/mcp",
  "authorization_endpoint": "https://api.openai.com/v1/tunnel/<tunnel-id>/mcp/oauth/authorize",
  "token_endpoint": "https://api.openai.com/v1/tunnel/<tunnel-id>/mcp/oauth/token",
  "grant_types_supported": ["authorization_code"],
  "code_challenge_methods_supported": ["S256"],
  "token_endpoint_auth_methods_supported": ["none"]
}

Problem

The OAuth endpoints advertised by discovery return 404 through the tunnel.

curl https://api.openai.com/v1/tunnel/<tunnel-id>/mcp/oauth/authorize

returns

404

Likewise

curl https://api.openai.com/v1/tunnel/<tunnel-id>/mcp/oauth/token

also returns

404

Because of this, ChatGPT never reaches the authorization step.

The coding-tools-mcp logs never show requests to:

GET /oauth/authorize
POST /oauth/token

tunnel-client logs

OAuth discovery URLs published ...

dispatcher received unsupported channel "harpoon"

harpoon host auto-registration failed

Question

Is Secure MCP Tunnel expected to proxy OAuth endpoints (/oauth/*) for MCP servers that implement their own OAuth Authorization Server?

Or is the expectation that the OAuth Authorization Server must already be publicly reachable outside the tunnel?

If the latter, what is the recommended architecture for MCP servers such as coding-tools-mcp that embed their own OAuth server?

[phil-merricks]

We’re seeing a related OAuth issue with Secure MCP Tunnel and ChatGPT connectors.

Setup:

• tunnel-client: v0.0.10
• OAuth issuer: Microsoft Entra ID, not an embedded MCP OAuth server
• MCP server is private/internal behind the tunnel
• Protected resource metadata discovery succeeds
• ChatGPT OAuth login appears to complete far enough that ChatGPT then tries MCP initialization

Observed behavior:

• ChatGPT sends MCP initialize / tools/list over the harpoon channel
• We patched a diagnostic tunnel-client build to route harpoon commands to the real MCP upstream
• The MCP server receives the request, but there is no Authorization header
• Server correctly returns 401 missing_bearer
• We also tested advertising OAuth support for harpoon; that did not cause a bearer token to be attached

So this does not look like a downstream Entra/JWT validation issue anymore. It looks like the Secure MCP Tunnel / ChatGPT connector path is not attaching the OAuth bearer token to MCP requests sent over harpoon, or the token is not present in the polled command payload.

Question:
Is OAuth bearer forwarding currently expected to work for tunnel-backed ChatGPT connectors when MCP traffic is delivered over harpoon? If so, is there a tunnel-client config requirement we are missing?

[denyska-oai]

Thanks for the detailed report. We investigated both behaviors in this thread.

Secure MCP Tunnel forwards OAuth discovery and metadata requests, but it does not expose an embedded authorization server at /v1/tunnel/<id>/mcp/oauth/*. The advertised authorization and token endpoints must be reachable by the product OAuth flow outside the tunnel.

The harpoon initialize / tools/list messages are an internal FastMCP control session and intentionally do not carry the connector bearer token. They must not be routed to the customer MCP upstream. After OAuth completes, runtime MCP traffic uses the configured main endpoint, where Authorization is forwarded.

We documented this boundary and added regression coverage. If a current build shows a request on main missing Authorization, please open a new issue with the channel and request trace.

[iNviNho]

Good day gentlemen,

Unfortunately, we hit the same wall as you @xlingsy . Both - authorization server and MCP server - on staging are behind firewall and tunneling only requests to MCP Server is not enough.

Can't OpenAI think about a solution to this problem? Can't we implement tunneling of requests to Authorization Server as well? There will be many companies who need to test their integration on their staging/test environments and allowing OpenAI or any other provider to call their staging services might seem problematic from security standpoint.

I am curious what is the future here.

Thank you

[hoffmanr-cshs]

This is going to be a blocker for us as well. If we're already going to have to expose the service to the internet / implement some sort of proxy for auth, then an MCP tunnel itself is of very little use. Because of the sensitive nature of our data (ChatGPT for Healthcare customer), exposing these things to the internet is generally not open for discussion - not to mention the development / testing / staging applications that would apply to most (if not all) enterprise customers. If we can't tunnel at least the back-channel token endpoint, I worry that we're just going to have to leave many connectors unsupported.

I hope that, at some point down the road, OpenAI @denyska-oai can reconsider tunneling the advertised OAuth endpoints!

[denyska-oai]

Thank you @hoffmanr-cshs for the detailed description. The no-public-ingress constraint is clear, especially for healthcare and non-production environments.

One nuance on the security tradeoff: in OAuth, the authorization server issues a token to the OAuth client; the client then presents an audience-bound token to the MCP server. In the ChatGPT connector flow, the product OAuth client already has to receive and use the access token.

The incremental risk of proxying the back-channel token endpoint is that it adds another trusted credential-handling path for the authorization code and PKCE verifier, any client-authentication material, the token response, and potentially refresh tokens. For ordinary bearer tokens, possession is sufficient for use, so every component that can terminate, inspect, queue, or log that exchange expands the disclosure surface. A hardened proxy is possible, but direct TLS between the OAuth client and authorization server is the smaller trust boundary when available.

Could you share a little more about your auth/identity topology? Please sanitized metadata as this is public forum:

• Is the authorization server embedded with the MCP server on the same origin, or is it a separate IdP/OAuth server such as Entra, Okta, etc?
• Can the end user's browser reach authorization_endpoint after joining VPN, while only ChatGPT's back-channel call to token_endpoint is blocked?
• Which endpoints are private: protected-resource metadata, authorization-server metadata, authorization, token, DCR, revocation, JWKS, or introspection?
• Is “VPN-only” reachable from the machine running tunnel-client, or only from a user device after interactive VPN login?
• Which tunnel-client version and token-endpoint authentication method (none, client secret, private_key_jwt, or mTLS) are you using?

Those details will tell us whether the narrow back-channel path covers this topology or whether there is a different enterprise case we still need to support.

Lets keep discussion open.