Val Town/Deno OAuth facade for https://mcp.superserve.ai.

Instead of putting a Superserve API key in the URL, MCP clients connect to the Val normally and complete an OAuth Authorization Code + PKCE flow:

1. The MCP client receives 401 with OAuth Protected Resource Metadata discovery.
2. It discovers /authorize, /token, and /register from the Authorization Server Metadata endpoint.
3. /authorize displays a small page where the user enters their Superserve API key.
4. The key is stored only in a short-lived, one-time authorization-code record (5 minutes) in the Val's scoped SQLite database.
5. /token verifies PKCE, deletes the code, and returns the Superserve API key as the OAuth Bearer access token.
6. The MCP client then sends Authorization: Bearer <token> on every request. The proxy forwards that header to Superserve.

The Superserve key is therefore never placed in a URL and is not retained in a long-lived token database by this proxy.

• /.well-known/oauth-protected-resource
• /.well-known/oauth-authorization-server
• /authorize
• /token
• /register (Dynamic Client Registration compatibility)

The authorization server also advertises Client ID Metadata Document (CIMD) support for current MCP clients. PKCE S256 is required.

Use the Val's normal public URL, for example:

https://superserve.val.run/

No api_key query parameter is needed.

• Superserve API keys are submitted in an HTTPS POST body, not a query string.
• Authorization codes are one-time, SHA-256 hashed in storage, and expire after 5 minutes.
• The underlying key is removed from scoped SQLite as soon as the code is redeemed.
• OAuth access is still bearer-token security: protect the MCP client's stored OAuth token because it is the Superserve API key.

ChatGPT's Client ID Metadata Document uses private_key_jwt at the token endpoint. The proxy advertises both none (for legacy/DCR public clients) and private_key_jwt. For CIMD clients using private_key_jwt, it fetches the client's HTTPS metadata and JWKS, verifies the RS256 assertion signature and validates iss, sub, aud, and exp before redeeming the authorization code.

OAuth remains the preferred flow, but the proxy also accepts a Superserve API key directly as:

https://superserve.val.run/?e2b_api_key=YOUR_SUPERSERVE_API_KEY

When present, e2b_api_key takes precedence over the OAuth Bearer token. The proxy removes the parameter before forwarding the request upstream and sends its value to Superserve as Authorization: Bearer ....

Query-string credentials can leak through browser history, logs, analytics, and referrers, so use this compatibility mode only where that tradeoff is acceptable.