v0.0.14: how to map an off-origin private OAuth AS with fixed Harpoon targets and RFC 9207?

[volpemauro]

I am looking for the supported configuration for a private OAuth authorization server on a different origin from the MCP server. Local discovery succeeds, but ChatGPT does not reach the AS through the tunnel. Custom target labels below are anonymized; URLs and observed behavior are unchanged.

Environment and expected contract

• Official tunnel-client 0.0.14, commit 0f870e5, Linux in WSL.
• Existing OpenAI Secure MCP Tunnel, ready.
• Private Streamable HTTP MCP: http://127.0.0.1:5197/mcp.
• Separate HTTPS authorization server issuer: https://127.0.0.1:5207/.
• Explicit trust of the existing local public AS certificate, hostname verification enabled.
• Redirects disabled; payload capture and raw HTTP logging disabled.
• Explicit private pre-registered public OAuth client mode in ChatGPT, token endpoint auth none, authorization-code + PKCE S256. No DCR, CIMD, OIDC identity scopes or refresh-token flow.
• The AS advertises authorization_response_iss_parameter_supported=true. Existing local regression tests pin the exact unchanged issuer in authorization responses; no ChatGPT login was performed in this trial. Issuer/audience checks must remain enabled.

Local observations

GET /mcp anonymously returns 401 with:

Bearer resource_metadata="http://127.0.0.1:5197/.well-known/oauth-protected-resource/mcp", scope="events:read"

GET that PRM URL returns 200:

{"resource":"http://127.0.0.1:5197/mcp","authorization_servers":["https://127.0.0.1:5207/"],"scopes_supported":["events:read"],"bearer_methods_supported":["header"]}

GET https://127.0.0.1:5207/.well-known/oauth-authorization-server/ returns 200 with issuer https://127.0.0.1:5207/, local browser authorization_endpoint /connect/authorize and token_endpoint /connect/token. The tunnel client's own startup AS discovery also succeeds. GET the issuer root anonymously returns 401 with no response body.

Configurations compared

Automatic private and loopback host classification are disabled. Plaintext HTTP is enabled for the exact local MCP targets. No redirect following.

The four-target registry contains:

• oauth-prmd-resource-0: http://127.0.0.1:5197/mcp (oauth, protected-resource-metadata/resource).
• oauth-prmd-source-0: http://127.0.0.1:5197/.well-known/oauth-protected-resource/mcp (oauth, protected-resource-metadata/source-url).
• local-as-metadata: https://127.0.0.1:5207/.well-known/oauth-authorization-server/ (config; no tags).
• local-as-token: https://127.0.0.1:5207/connect/token (config; no tags).

For one specifically approved discovery-only trial, exactly this fifth target was added:

• local-as-issuer: https://127.0.0.1:5207/ (config; no tags).

These are exact URL targets, not path prefixes. Browser authorize/account routes and JWKS were not registered. Harpoon's generic method set is GET/POST/PUT; application route/method and authentication controls remain at the local AS. No token POST, login, consent or app creation was performed in this trial.

Actual product observation

In the ChatGPT Create Plugin dialog, select the existing tunnel and OAuth, then open the advanced OAuth settings to trigger discovery.

With either registry, the product invokes Harpoon GET oauth-prmd-source-0 and gets HTTP 200. With the five-target registry, this refresh produced two successful PRM requests at 2026-09-07T21:24:30.818805752Z and 2026-09-07T21:24:31.91567641Z.

No call to the AS metadata, issuer root or token target followed. The OAuth authorization URL, token URL, AS base, resource and scope fields remained empty. No OAuth-specific warning/error was captured by the browser console inspection.

An earlier connector attempt showed the generic “does not implement OAuth” error. App creation was not submitted or reproduced in this trial; the directly observed boundary is successful PRM fetch followed by no AS call and empty discovery fields.

Source evidence and unresolved question

In v0.0.14:

• runtimeharpoon/transform.go rewrites only exact known URLs. Adding the issuer-root target makes authorization_servers[0] eligible for rewriting.
• runtimeharpoon/shared_wiring.go ConvertTargets assigns config category/source and no tags to manual targets.
• runtimeconfig/file_config.go and the public CLI target syntax have no OAuth category/role/group fields.
• oauth/hostbundle.go sets DisallowPrivateHostRegistration for the off-origin AS. runtimeharpoon/host_registration.go does not promote this separate HTTPS origin through the MCP-origin rule.
• docs/architecture.md says AS metadata uses Tunnel when its issuer is rewritten to a Harpoon-backed route; browser authorization stays direct.

What supported configuration maps this separately hosted private AS into the official OAuth shim using only explicitly registered URLs, with the required OAuth role/group association?

What exact issuer does ChatGPT retain from shimmed AS metadata, and how does it preserve equality with the browser-direct RFC-9207 iss response? Please provide a supported configuration or identify the client/service change required. Adding a root mapping alone did not make the AS request occur. We are not requesting a validation bypass, a broad AS-origin exposure, or an arbitrary proxy.

Primary sources

• https://github.com/openai/tunnel-client/blob/v0.0.14/docs/architecture.md#oauth-protected-mcp
• https://github.com/openai/tunnel-client/blob/v0.0.14/pkg/runtimeharpoon/transform.go
• https://github.com/openai/tunnel-client/blob/v0.0.14/pkg/runtimeharpoon/shared_wiring.go
• https://github.com/openai/tunnel-client/blob/v0.0.14/pkg/runtimeconfig/file_config.go
• https://github.com/openai/tunnel-client/blob/v0.0.14/pkg/oauth/hostbundle.go
• https://github.com/openai/tunnel-client/blob/v0.0.14/pkg/runtimeharpoon/host_registration.go
• https://developers.openai.com/plugins/build/auth

[blev8824-ai]

The interesting detail is the PRM discovery succeeds but no authorization_server call follows. The protected-resource metadata is fetched, then the client stops, so the off-origin HTTPS AS issuer is not carried into tunnel-rebased discovery and there is no route to rewrite the AS origin. The piece to pin is issuer equality under RFC 9207: the client must compare the issuer it resolved from tunneled metadata against the iss in the browser-direct authorization response. If the shim rewrites the AS base but not the iss the real server emits, the equality check fails and a working flow becomes a silent issuer mismatch. Worth a test that asserts the exact issuer string the client compares, before adding AS route mapping. That issuer and audience integrity check is the delegated-authorization guarantee AgentKey validates on the decisions it signs: https://agentkey.us

[volpemauro]

Update (2026-09-08): hosted ChatGPT discovery, OAuth code exchange, tool discovery, and an actual read-only tool call now work end to end with a private diagnostic build based on v0.0.14. The tool returned one synthetic development event.

We have confirmed errors in our own implementation and diagnostic patch; we have not established a bug in the hosted OpenAI service. This narrows the original question, but does not yet demonstrate a supported solution using the unmodified released client.

Controlled discovery comparison

Our first diagnostic patch incorrectly combined the PRMD authorization-server role and the AS-metadata issuer role on one target label.

• A used the canonical AS metadata URL without a trailing slash, but retained those merged roles. Fresh ChatGPT discovery produced PRM GET 200, then issuer-root GET 401; there was no AS-metadata request.
• B kept the same canonical metadata URL and separated the two roles onto distinct labels for the same exact, already allowed issuer-root URL, associated with the metadata/token targets in the same OAuth group. Fresh ChatGPT discovery produced PRM GET 200 followed by AS-metadata GET 200, and ChatGPT populated its OAuth fields.
• Both variants used the same five distinct destination URLs. B had six catalog entries because two role labels shared the issuer-root URL; it did not permit another destination.

This supports a role/catalog association problem in our diagnostic configuration rather than a claim that the hosted service necessarily chooses the wrong target. We did not run a separate split-role test with the old trailing-slash metadata URL, so we cannot isolate the slash change as independently necessary.

Local application fixes and completed validation

After discovery succeeded, we also corrected problems in our own AS/MCP implementation:

• The local PRM transport URL in the MCP challenge must remain separate from the canonical tunnel resource identifier used for the resource/audience contract.
• Our AS changed Referrer-Policy from no-referrer to strict-origin, so native browser form POSTs satisfy its existing exact-Origin check without referring OAuth paths or query strings.
• Only the consent page now permits the already validated, exactly registered callback in CSP form-action; password/MFA forms retain their local-only policy.

After a fresh personal login and consent, the authorization code was redeemed in about three seconds and the tunneled token endpoint returned HTTP 200. ChatGPT loaded the tool catalog; a real tool call then completed the separate local token exchange and returned synthetic event data.

Plaintext HTTP remained explicitly opted in for the trusted local MCP targets. AS TLS/hostname verification, application issuer/audience validation, PKCE, CSRF, and exact callback checks stayed enabled. Redirect following in the tunnel remained disabled. No additional distinct tunnel destinations or firewall changes were needed.

Our AS continues to emit its exact configured local issuer in the RFC-9207 response. The successful callback/code exchange is operational evidence, but we have not observed ChatGPT's internal issuer-comparison string and do not infer its exact comparison/rewrite implementation from that success alone.

Remaining question

What is the supported way for explicitly configured, off-origin private AS targets to acquire the required OAuth role/group association while retaining an exact URL allowlist, without a private client patch?

The latest published release is still v0.0.14. I also checked the relevant changes on master through 788773034dd3f53e112f140feab99e90e75ee22a: these include discovery retry improvements and clearer loopback-HTTP remediation, but I did not find an exposed configuration mechanism for this role association. I have not run that newer master build.

I am leaving this issue open for that remaining supported-configuration question. The original end-to-end setup blocker is worked around locally; it is not evidence that the unmodified official-client configuration requested here has been resolved.