Separating shared keys from per-user OAuth for MCP servers

On 5 November 2026, a Stack Overflow question asking whether Claude Desktop can open an authorization URL and accept a token without OAuth 2.0/PKCE had 749 views, and a second question about passing an API key to tool calls in a remote MCP server deployed on Cloudflare had 605 views. On 10 November 2026, DEV Community published "MCP server 架在已有 API 上：共享 key 还是逐用户 OAuth" (Building an MCP server on top of an existing API: shared key or per-user OAuth), which cited both questions and argued that authentication is where builders get stuck first when they expose an MCP server over an existing API.

The same day, the author went through the MCP specification and the connector documentation for Claude and ChatGPT, and noted that both clients reach a remote server through Streamable HTTP. From this, the article draws a distinction that it says MCP server developers need to keep in mind: the server holds its own credentials for calling the upstream API, while each user authorizes separately on the MCP side. When API permissions need to vary per user, the recommendation is to run authorization directly against your own API rather than forwarding the MCP access token through. Nothing in the available material indicates any follow-up discussion, adoption, or revision of this approach after the article was published.