A remote MCP connector has to answer an OAuth discovery before Claude will talk to it, and most MCP servers cannot. That gap is the entire reason the category "MCP OAuth proxy" exists. Here are the five ways to fill it, and the one question that decides between them.
Why this category exists at all
Register an MCP server as a connector and Anthropic's infrastructure connects to it on behalf of a signed-in user. That path expects OAuth: an authorization server it can discover, and PKCE. Most self-built servers and most workflow endpoints do not offer one, so something has to sit in between and speak OAuth on the server's behalf. That something is what this article compares.
Check one thing before you build any of it: whether your server has grown the capability while you were not looking. n8n's MCP trigger did, in version 2.27.0 of June 2026, and its documentation still says otherwise, so the most common reason to reach for a proxy is now often obsolete. The details are in the n8n setup guide.
One correction worth making up front, because it shapes what people expect from these tools: this is not a "web versus desktop" problem. A remote connector behaves the same in Claude Desktop as on claude.ai, because both go through the same infrastructure. What differs is running a server locally over stdio, where nothing is authenticated because nothing crosses a network. The mechanics are in MCP authentication for claude.ai: what actually works.
The five options
- A local server, or
mcp-remoteas a local bridge. Not a proxy at all: you sidestep the requirement by never registering a connector. Right for one person on one machine who does not need mobile, colleagues or an audit trail. - sigbit/mcp-auth-proxy, self-hosted. The most widely used of the open source options, MIT licensed and actively maintained. It describes itself as
a secure OAuth 2.1 authentication proxy for Model Context Protocol (MCP) servers
and brings its own identity provider integrations, Google, GitHub, Okta, Auth0, Azure AD and Keycloak among them, with user matching by exact address or glob. Free. You run it, patch it and keep its configuration in step with your tunnel. - Other open source proxies. obot-platform/mcp-oauth-proxy and AthenZ/mcp-oauth-proxy solve the same shape, the latter aimed at enterprise-managed authorization. Smaller communities, so read the commit history before you depend on one.
- Build the endpoints into your own server. Full control over every behaviour, and from then on you maintain auth-critical code: discovery, PKCE, token lifetimes, rotation.
- A hosted service, such as Loopthink. You point it at your server, it provides the OAuth endpoints, connects your identity provider, and logs each tool call under the name of the person who made it. This is our product, so weigh this row accordingly.
The comparison
| Local bridge | Self-hosted proxy | Own implementation | Identity-aware proxy | Hosted (Loopthink) | |
|---|---|---|---|---|---|
| Works as a remote connector | No, by definition | Yes | Yes, once discovery is right | Yes | Yes |
| Reaches mobile and other machines | No | Yes | Yes | Yes | Yes |
| Runs as the person who asked | No, one token | No, the upstream sees the proxy | If you build identity passthrough | Knows the person at the door, not at the tool | Yes |
| Audit per tool call | No | Request logs, no tool semantics | If you build it | HTTP logs, no tool semantics | Yes |
| Reaches servers not exposed to the internet | Yes, it runs locally | Yes, it runs next to the server | Yes | Through a tunnel | Yes, outbound-only runner |
| Field masking before the model sees data | No | No | If you build it | No, or enterprise DLP that knows nothing of tools | Yes, optional |
| Who maintains it | You | You | You, indefinitely | The vendor, plus your configuration | Us |
| Price | Free | Free, plus a server | Your time | Free tier, then per user | Free for your own server, then from €49/month |
The question that separates them
Connection or person. Every option authenticates a connection. Only some carry the person through to the other side.
The concrete version: two colleagues share a connector in front of your CRM. One of them pulls the full customer list into a chat. Six months later somebody from compliance asks who did that. With connection-level auth the log has one answer for both colleagues, and it is the proxy's name. With per-user identity it has a name, a timestamp and the tool that was called. If nobody in your organization will ever ask that question, you do not need to pay for the answer. If somebody will, this row decides the table.
When you should not buy anything
One MCP server, one user, and you enjoy maintaining infrastructure: take sigbit/mcp-auth-proxy, it is free, MIT licensed and it works. The same goes for a personal n8n instance you only reach from your own machine: a local bridge needs no proxy at all. Buying a hosted service to solve a one-person problem is overspending, and we would rather tell you that here than have you discover it on an invoice.
If it is more than one person
Then the shared-identity ceiling is real, and that is what we sell past: OAuth that Claude and ChatGPT accept, your own identity provider behind it, every call running as the person who asked, and one audit log across both assistants. Free for the MCP servers you already run, up to five connectors, no card. Team at €49 when a second person needs access or we build the server for you out of an API, a SQL database or Search Console.