Almost every guide to putting an n8n workflow into Claude tells you the MCP trigger cannot do OAuth, so you need a proxy in front of it. That was true until 16 June 2026. It is not true now, n8n's own documentation still says it is, and that combination is why people keep building proxies they may not need.

What changed, and why nobody noticed

n8n 2.27.0 added a third authentication option to the MCP Server Trigger, n8n User Auth (OAuth2), alongside Bearer and Header auth. Behind it sits a real authorization server: n8n publishes OAuth 2.0 authorization server metadata at /.well-known/oauth-authorization-server, advertises S256 as a PKCE method, exposes a registration endpoint for Dynamic Client Registration, and serves Protected Resource Metadata under /.well-known/oauth-protected-resource. Since a follow-up fix on 20 July 2026 it also answers an unauthenticated request with 401 and a WWW-Authenticate header pointing at that metadata, which is the discovery path Anthropic documents as the primary one.

That is, point for point, the chain a remote connector needs. It runs in four steps, and n8n answers at every one of them:

CLAUDE ASKSN8N ANSWERS1GET /mcp/your-pathno token yet401 WWW-Authenticate: Bearerresource_metadata="…/.well-known/oauth-protected-resource…"2GET that metadataRFC 9728authorization_servers: [ … ]which server issues tokens for this resource3GET /.well-known/oauth-authorization-servercode_challenge_methods_supported: ["S256"]plus authorization, token and registration endpoints4Authorization code flow, with PKCEthe user signs inA token, and a connector that worksevery call now carries the person who signed in
Step 1 is the one n8n gained last, in July 2026. Without it Claude falls back to probing well-known paths, which is documented but slower to get right.

Three things kept all of this invisible:

  • The documentation is behind the code. n8n's MCP Server Trigger page still lists only Bearer auth, Header auth. If you check the docs before believing a forum post, the docs confirm the forum post.
  • The option is gated on node version 2. An existing workflow whose trigger node predates that version does not show the option at all, even on a current n8n. So one person swears it is there and another swears it is not, and both are looking at the truth.
  • The feature request is still open. The community thread from 8 March 2026 is the top result, and its last reply, from 9 June 2026, recommends a proxy. That reply is a week older than the release. The thread is not open because the feature fell short; it is open because nobody went back to close it.

Both paths below are tested, not inferred

We ran them. The native path and the proxy path each got a connector into Claude and answered tool calls from a workflow. That matters because there is no public write-up of either, in any direction: the threads people find are older than the feature, so the internet's answer to "does n8n do OAuth" is a year out of date and confidently wrong. What follows is what worked, in the order that made it work.

Path A: n8n's own OAuth

The shortest route, and free. Use a current n8n; the discovery chain was only completed in late July 2026, so an instance from June has the option but not the fix.

  1. Add a new MCP Server Trigger to the workflow. If you are editing a workflow that already has one and the option is missing, that node is on an older version, and adding a fresh one is faster than arguing with it.
  2. Set Authentication to n8n User Auth (OAuth2).
  3. Decide on require execute access, which defaults to on. It means the person signing in must also be allowed to execute that workflow in its project. Leave it on unless you know why you are turning it off.
  4. Activate the workflow and copy the Production URL. The production endpoint only exists while the workflow is active; the test URL dies with your editor session.
  5. Add that URL as a custom connector in Claude and complete the sign-in.

The limit of this path is not technical, it is organisational: everyone who uses the connector authenticates as an n8n user and needs execute permission on the workflow. For a team that already lives in n8n, that is exactly right, and it gives you per-user identity for free. For a connector you want to hand to customers, or to colleagues you are not about to give n8n accounts, it does not fit.

Path B: an OAuth proxy in front

Still the answer when the callers should not be n8n users, or when your n8n is too old to upgrade right now. sigbit/mcp-auth-proxy is the most used option, MIT licensed, and describes itself as a secure OAuth 2.1 authentication proxy for Model Context Protocol (MCP) servers. It terminates the OAuth flow against an identity provider of your choice, Google, GitHub, Okta, Auth0, Azure AD or Keycloak among them, and forwards to your trigger with its bearer token attached.

Set the trigger to Bearer auth, give the proxy the public hostname and point it at the trigger's production URL. The proxy is the easy half; the tunnel below is where evenings go.

Path C: hosted

The paid path, and labelled honestly: this is our product. Paste the trigger's production URL and its bearer token into Loopthink, choose which of the workflow's tools are exposed and who may call them, then install the connector URL in Claude. The same URL works in ChatGPT. You get OAuth that both accept, sign-in against your own identity provider rather than against n8n, and an audit entry per tool call naming the person who made it. Free for the servers you already run, pricing here.

The tunnel settings, whichever path you took

If your n8n sits behind a reverse proxy or a tunnel, this is where a working OAuth flow still ends in a dead connection. Order matters, because the first setting changes what the others see:

  1. Tell n8n how many proxies are in front of it. N8N_PROXY_HOPS, a number, default 0: Number of reverse-proxies n8n is running behind. Set it to 1 for a single tunnel or proxy. You will find N8N_TRUST_PROXY=true in blog posts and forum answers; it is not in n8n's environment variable reference, and there are threads from people watching it do nothing. Until the hop count is right, n8n builds its URLs from the internal hostname, and every URL it publishes in discovery is wrong, which breaks OAuth in a way that looks like anything but a proxy setting.
  2. Set the public hostname on the forwarded request. In a Cloudflare Tunnel that is httpHostHeader, which Sets the HTTP Host header on requests sent to the local service.
  3. Consider disabling chunked encoding. In a Cloudflare Tunnel, disableChunkedEncoding. Cloudflare documents this for WSGI servers, not for streaming, and there is no vendor statement that MCP needs it. It is a field remedy worth trying when a connection establishes and then dies, not a documented requirement, and it applies to HTTP/1.1 only.
  4. Allow WebSocket upgrades, so an upgrade request reaches n8n instead of being answered by the tunnel.
# cloudflared config.yml, the relevant ingress rule
ingress:
  - hostname: n8n.example.com
    service: http://localhost:5678
    originRequest:
      httpHostHeader: n8n.example.com
      disableChunkedEncoding: true

Troubleshooting

The connector fails and your n8n log shows nothing at all

Not a tunnel problem: the request was never sent. Anthropic states that Claude rejects the connection before any HTTP request leaves Anthropic's network. Your hostname resolves to a private range (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, CGNAT 100.64.0.0/10), or it publishes only AAAA records and connectors are IPv4 only, or split-horizon DNS hands the public internet an internal address. Check what your hostname resolves to from outside your network, not from your laptop.

Authorization fails, and the flow never reaches a login screen

Discovery. Fetch /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource on the public hostname and check that both answer, that the URLs inside them are public rather than internal, and that no redirect sits between the connector URL and the server. A cross-host redirect drops the Authorization header, so what arrives is anonymous.

It authenticates, then times out

Your endpoints get up to 10 seconds for discovery, registration and token responses, and 30 seconds for a refresh. A cold start in front of a slow identity provider fails on time alone, with everything configured correctly.

The OAuth2 option is not in the dropdown

Either your n8n predates 2.27.0, or the trigger node in that workflow is on an older node version. Add a new MCP Server Trigger and check again.

Someone signs in successfully but sees no tools

With n8n User Auth (OAuth2) and require-execute-access on, the person needs permission to execute that workflow in its project. Check their role in n8n rather than the connector.

Sources

Checked on 27 August 2026. The n8n behaviour was read from the node's source and release history, not from its documentation, which is out of date on this point.