Proposal: optional external JWT authorization for private DevSpace deployments

[aimaster486]

Proposal: optional external JWT authorization for private DevSpace deployments

Security and privacy

DevSpace's embedded single-owner OAuth server is a good default and should remain unchanged.

For remote use, its OAuth endpoints need a public HTTPS origin. The hostname can appear in DNS or certificate records, or leak through configuration, revealing the deployment and giving scanners a stable target.

Those routes share a process with DevSpace's local workspace, process, and shell access. OAuth controls tool use, but cannot remove the pre-authentication attack surface. A stricter deployment should be able to keep every DevSpace route private.

Current community progress

Issue #182 now has an open implementation in PR #259. It keeps DevSpace OAuth and proposes separating the issuer and MCP resource URLs, allowing the MCP host to obtain a DevSpace access token for the tunnel resource. DevSpace would still remain the public authorization server.

The workaround in #182 takes a different path: the MCP host is configured with no authentication, so requests reaching the local proxy contain no DevSpace access token. The proxy uses the Owner credential (ownerToken) to complete OAuth on loopback, keeps the resulting access token in memory, and injects Authorization: Bearer ... before forwarding.

The tunnel still has OpenAI access controls, but DevSpace authentication is no longer end-to-end. The proxy turns admitted tunnel requests into authenticated DevSpace requests and becomes a privileged credential holder. This is the main limitation of the workaround.

Proposal

Add an optional external JWT mode alongside embedded OAuth:

Browser -> external authorization server -> short-lived JWT
MCP host -> Secure MCP Tunnel -> loopback DevSpace -> local JWT verification

The external service handles the required OAuth flow and issues a short-lived JWT. MCP requests reach loopback-only DevSpace through the tunnel. DevSpace validates the signature and expected claims locally using public keys.

Beyond the JWT contract and public verification keys, the two services share no state or credentials.

As a reference deployment, I would host only the OAuth service on Cloudflare. It would issue short-lived JWTs, while OpenAI Secure MCP Tunnel forwards /mcp requests to loopback-only DevSpace. DevSpace would hold only the public verification keys and would have no public hostname of its own.

Embedded OAuth remains the default. The extension should be provider-neutral; this Cloudflare and OpenAI setup is an example, not a requirement.

Question

Would this optional authorization boundary be within DevSpace's scope after #182 and #259? If so, I can follow up with a small staged design before submitting code.

[aimaster486]

Thanks benrrr56-wq— the threat model is simpler than my original wording made it sound.
Secure MCP Tunnel is the starting point. In the workaround described in #182, ChatGPT connects as unauthenticated and a local proxy adds a DevSpace credential to every admitted request. Tunnel admission therefore becomes effectively equivalent to DevSpace authorization. If the OpenAI account or session with access to that tunnel is compromised, the attacker can inherit the machine authority exposed by DevSpace without another approval step.
I want to keep application-level OAuth as that second gate. As far as the current OpenAI documentation shows, the MCP resource can stay private, but the browser-facing authorization server still needs a public URL. If there is a supported way to keep that server private while preserving end-to-end authentication, I would prefer it and this proposal may be unnecessary.
An external authorization server does not require JWT. With opaque tokens, however, private DevSpace would normally need an online validation call to the public authorization service. That creates a small but avoidable link: the service, or its logs if compromised, could observe the local machine’s egress IP.
Offline JWT verification removes that connection. The public service knows only the logical tunnel resource, while DevSpace holds only the public verification key and validates every request locally. A compromised issuer could still mint tokens, but it would have no direct connection to the private DevSpace address.
The JWT would be bound to the exact tunnel-backed DevSpace MCP resource and expire after 15 minutes. Refresh authorization would have a configurable absolute limit—12 hours as a practical default, with 4 or 8 hours also reasonable—and rotation would never extend that deadline. After it expires, Owner approval is required again.
For my personal threat model, these are the two important controls: reaching the tunnel is not enough to use DevSpace, and the public authorization service does not need to know how to reach the local machine. This does not make remote access identical to local Codex, but brings it much closer to a local-only security posture.