> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Choosing a Remote Server's Authentication Method
> How to decide which of MCP Manager's three remote-server authentication methods to use — standard OAuth with dynamic client registration, OAuth with client pre-registration, or a token in custom headers — including what to do when automatic OAuth fails and when to fall back to a workstation server.
When you add a [remote MCP server](/mcp-gateway-concepts/mcp-servers/remote) by URL, **MCP Manager** first tries **standard OAuth automatically**. If that succeeds you're done — there's no decision to make. You only choose a method when automatic OAuth doesn't connect, or when a server offers more than one way in and you want to pick deliberately. This page is that decision: which of the three methods to use, and what to do when the automatic path fails.
For the mechanics of each method — what MCP Manager does on the wire, where credentials are stored, and how token refresh works — see [Authentication & Identity](/security/authentication-and-identity). This page is about *choosing*; that page is the reference.
Adding a remote server and creating its identities is gated by the **Basic server management** capability. See the [capabilities reference](/deployment/rbac-and-roles/capabilities).
## The three methods at a glance
| Method | Choose it when | What you provide |
| ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **Standard OAuth (dynamic client registration)** | The server supports dynamic client registration — MCP Manager registers itself and runs the whole flow. Atlassian's MCP server works this way. | Nothing but the URL; you approve a consent screen. |
| **OAuth with client pre-registration** | The server requires you to create an app in its developer portal first. Asana, HubSpot, and Slack are common examples. | A **Client ID** and **Client Secret**, plus MCP Manager's callback URL entered in the provider. |
| **Token in custom headers** | The server authenticates with an API key or bearer token instead of OAuth — and often when you want tighter, more stable scoping. | The header name and value (for example `Authorization: Bearer …`). |
All three end the same way: MCP Manager holds the credentials and attaches them to every request it makes on your behalf, [encrypted with AES-256-GCM](/mcp-gateway-concepts/mcp-servers/remote#how-your-credentials-are-secured).
## Token versus OAuth, when you have the choice
Some servers accept more than one method — GitHub, for instance, takes both OAuth and header tokens — and some don't make it obvious how a non-Claude/Cursor client should connect. When the choice is yours:
* **Token authentication** is often more customizable — scope definition is usually part of creating the token — and tends to be more stable over time.
* **OAuth** is usually easier for non-technical users: you approve a consent screen in a pop-up instead of generating a token deep in a developer-settings menu.
## When automatic OAuth doesn't work
If MCP Manager can't connect a server with standard OAuth, fall back to **client pre-registration** (Client ID and Secret). Automatic OAuth fails for one of three reasons:
* **The server requires clients to be registered ahead of time.** Slack is a good example — it only accepts a confidential OAuth client you registered yourself.
* **The server doesn't support dynamic client registration** at all, so there is no way for MCP Manager to register itself on the fly.
* **The server allows only an allowlist of well-known clients** (Claude, Cursor, Goose), and you must register MCP Manager as a client app to be on that list.
In each case, create an app in the provider's developer portal, then give MCP Manager the resulting Client ID and Client Secret and add its callback URL to the provider — see [OAuth with client pre-registration](/security/authentication-and-identity#oauth-with-client-pre-registration). The per-vendor [server guides](/mcp-server-guides/overview) walk through this for specific providers.
## When a server allows no custom clients at all
If a server permits no custom clients of any kind, it typically still allows `localhost`. In that case you can run it locally through MCP Manager as a [workstation server](/mcp-gateway-concepts/mcp-servers/workstation), which connects over an encrypted tunnel instead of a public URL.
## Further reading
What remote servers are and how a remote request flows through the gateway.
The reference for each of the three methods — the flow, storage, and refresh.
How MCP Manager detects a server's authentication type, and per-vendor guides.
The local-tunnel fallback when a server allows no custom clients.