Skip to main content

Authentication: Connector vs Proxy Modes

Open the Setup tab on two different MCP servers and you can see two entirely different lists of authentication modes. This is not a bug or a versioning artifact. Which modes Willow offers depends on who owns the connection to the upstream service, and that is decided when the server is added.

Two kinds of relationship​

The question underneath every mode is the same: whose credential reaches the upstream service? Willow answers it differently depending on whether it knows the service.

When you add a Willow connector, Willow already understands the service. It holds the endpoint, the tool definitions, and often a registered OAuth application. The modes describe whose account is used: Willow's own app, your organization's app, one shared key, or one key per person. These servers report Built-In transport, and their Settings tab has no MCP Configuration section, because there is nothing for you to configure.

When you add a custom server on HTTP or STDIO, Willow knows nothing about what is on the other end. You supply the configuration, and Willow's job is narrower: take the caller's credential and forward it. That is why every mode in this set is named Proxy something. It describes what Willow does to a credential in transit rather than which account it belongs to.

The two sets never appear together. A mode named in one is not available in the other.

Why connectors do not all match​

Even among connectors the set varies, because Willow can only offer what the upstream service supports and what Willow has arranged in advance.

Instant OAuth is the clearest case. It works because Willow maintains a registered application with that service, so you supply no credentials at all. That is only possible for a service Willow knows by name. The generic MCP from API connector wraps whatever API you point it at, so no such app can exist, and it offers API Key, Client Credentials, API Key Per User, and None instead.

The practical consequence: treat a documented list as the common case and the Setup tab of the server in front of you as the authority.

Why the proxy modes are more granular​

Custom servers get five modes where connectors get four or five, and the extra granularity is about who is calling rather than what the service is.

A human user has an interactive session, so Willow can run an OAuth flow on their behalf or ask them for a key. A machine user has neither. Proxy Client Credentials and Proxy Passthrough exist for that case: the first mints one service token for every caller, the second forwards whatever the caller already holds, minting a client-credentials token when the caller is a machine user. This is why only None, Proxy Client Credentials, and Proxy Passthrough work for machine users at all.

Connectors do not need that distinction, because a connector is something a person authorizes.

Where to go next​

On this page