Distribute · Authentication
Authentication
MCP server authentication answers two separate questions: who is calling the server, and which credential the server uses upstream.
Authentication on an MCP server answers two questions that are configured independently and are easy to confuse:
- Who is calling this MCP server? Answered by user sessions, where the Control Plane acts as the authorization server and issues tokens to MCP clients.
- What credential does the server use to call the upstream API? Answered either per end user, with remote identity providers, or with one shared credential for every caller.
A server can use one, both, or neither. A server with no answer to the first question and no answer to the second is an anonymous server proxying an unauthenticated upstream.
Picking a model
Section titled “Picking a model”| Goal | Use | Per end user? |
|---|---|---|
| Only organization members can connect, using their Speakeasy login | User sessions on a private server | Identity only |
| Anyone can connect anonymously, with no login | Public visibility, which requires a tunneled backend and the tunnel source owner’s consent | No |
| Each end user acts against their own account on an upstream service | Remote identity providers, layered on user sessions | Yes |
| One shared credential for the whole server | Environment system variables or upstream headers | No |
| Each connecting user supplies their own API key | Environment variables marked as user-provided | Yes |
Two composition rules follow from how these are stored:
- Per-user upstream credentials require user sessions. An upstream token is stored against the calling user, so the server has to know who that is first.
- Shared credentials compose with anything, including a fully anonymous public server.
Two similarly named concepts run in opposite directions. User sessions are inbound: tokens the Control Plane issues to an MCP client so it can reach the server. Remote sessions are outbound: upstream tokens the Control Plane holds on an end user’s behalf so the server can reach a third-party API. Session Duration governs the first. Reconnect prompts belong to the second.
Where it is configured
Section titled “Where it is configured”The server detail page’s Authentication tab carries both halves, described in the product as configuring user sessions and, when required, upstream identity providers for clients connecting to this server.
Changing authentication settings requires the mcp:write scope. Creating and managing remote identity providers is an organization-level action and requires org:admin.
Authentication changes apply to new client connections. Clients already holding a valid token keep working until that token expires.
Anonymous access
Section titled “Anonymous access”Public visibility skips authentication entirely: any caller reaches the server with no login and every tool is exposed to the public internet. It is available only on tunneled servers whose source owner has opted in, and it is a deliberate double opt-in rather than a general visibility option.
A public server still uses its own credentials. Attached system environment variables and configured upstream headers are sent on every call, including calls from anonymous users. Public means anonymous callers get to spend those credentials, not that the credentials are withheld.
External servers
Section titled “External servers”Two guides cover OAuth against an authorization server outside the Control Plane, on toolset-backed servers:
- Secure an MCP server with OAuth covers the OAuth credential styles those servers accept: pre-obtained access tokens, the client credentials flow, and several security schemes in one OpenAPI document.
- Build MCP with external OAuth covers pointing clients at a third-party authorization server directly.
Both advertise OAuth scopes, and both handle token storage and revocation differently from user sessions.