MCP server authentication: OAuth, tokens, and safe remote access

MCP server authentication is how an MCP server decides who may call it. The answer changes with the transport. A local server running over standard input and output (stdio) reads credentials from its own environment. A remote server reached over HTTP acts as an OAuth 2.1 resource server and checks an access token the client presents on behalf of a user.

Authentication and authorization are separate steps. Authentication confirms which client is calling. Authorization decides which tools and scopes that client may use, and a server re-checks it on every tool call.

Key takeaways

• Authentication confirms who is calling. Authorization decides what they may do, checked per tool call.
• Remote HTTP MCP servers use OAuth 2.1 with PKCE and publish Protected Resource Metadata so a client can find the authorization server.
• MCP clients send the RFC 8707 resource parameter, and servers reject tokens issued for a different audience.
• Local stdio servers skip the HTTP flow and take credentials from the environment, which makes local config part of the security boundary.
• An MCP access token and a provider token are different credentials. A server must not pass its inbound MCP token through to an unrelated API.
• An access token often lives about an hour, as with Google. Anything longer needs token refresh.

How does authentication work for a remote MCP server?

A protected remote server behaves as an OAuth 2.1 resource server. The exchange follows the MCP authorization specification (revision 2026-07-28, checked 16 September 2026):

1. A client calls the server without a token and gets 401 Unauthorized with a WWW-Authenticate header that carries a resource_metadata URL.
2. The client fetches that Protected Resource Metadata document (RFC 9728) and reads the authorization server it names.
3. The client discovers the authorization server's endpoints through OAuth 2.0 Authorization Server Metadata (RFC 8414) or OpenID Connect Discovery.
4. The client runs an authorization code flow with PKCE (RFC 7636), including the resource parameter that names the MCP server.
5. The client retries the call with Authorization: Bearer <access-token>.

The server validates the token on every request and must confirm it was issued for that server as the intended audience. An invalid or expired token gets a 401.

The authorization server can run alongside the MCP server or as a separate identity service, such as Auth0 or Microsoft Entra ID.

A real unauthenticated call to ClawLink's remote MCP server on 16 September 2026. The 401 names the metadata document that starts the OAuth flow.

How does a local STDIO MCP server authenticate?

A local server that talks over stdio does not use the HTTP authorization flow. The specification says stdio implementations should not follow it, and should take credentials from the environment instead.

That is practical for a developer tool, but it makes local configuration part of the security boundary. A long-lived provider token in a repository, a shell history file, or a shared config file is readable by anything running as that user. Keep those tokens out of version control and out of the model's context.

Which credentials do people mix up?

Three credentials look interchangeable and are not.

A Gmail token does not prove that an MCP client may call your MCP endpoint, and an MCP access token should not become a Gmail token. The specification is explicit: an MCP server must not accept or transit any token other than one issued by its own authorization server for its own resource.

Who should hold the credential?

The real comparison is not OAuth versus no OAuth. It is who runs the authorization server and who holds the app credential.

Building the remote server yourself is the most work and gives the most control. A hosted connector removes the authorization server, the token storage, and the refresh loop from your side, at the cost of trusting the vendor's infrastructure.

What does the MCP authorization specification require?

The specification layers a selected subset of OAuth 2.1 on top of existing RFCs. The parts an implementer has to get right:

• OAuth 2.1 for authorization servers. Authorization servers must implement OAuth 2.1 with the security measures for confidential and public clients.
• Protected Resource Metadata is mandatory. MCP servers must implement RFC 9728, and clients must use it to discover the authorization server.
• The resource parameter is mandatory. Clients must send RFC 8707 Resource Indicators in both the authorization and the token request, naming the MCP server.
• Audience validation. Servers must validate that a token was issued for them, and reject any other token.
• Client registration. Clients get a client ID through a Client ID Metadata Document, a pre-registration, or Dynamic Client Registration (RFC 7591), which is deprecated but retained for older servers.
• Least-privilege scopes. A 401 can carry a scope value in the WWW-Authenticate header. When a call needs more scope, the specification defines a step-up flow that re-authorizes with the union of the old and new scopes.

RFC 9207 issuer identification matters here too. The client records the authorization server's iss value and checks it on the callback, which closes an authorization server mix-up attack.

What do the auth error codes mean?

The specification maps failures to three status codes.

A 403 with error="insufficient_scope" is the specification's signal to re-authorize with more scopes, not an error to retry as-is.

How does ClawLink handle MCP server authentication?

ClawLink takes the hosted route. For most OAuth apps, Composio runs the hosted OAuth flow and holds the provider's access and refresh tokens as our subprocessor, while ClawLink stores only an opaque reference to the connected account. For the few apps connected through a vendor's own MCP server, ClawLink runs the flow and holds those vendor tokens itself, encrypted. The credentials ClawLink stores directly are those vendor tokens and any API keys a user enters, encrypted with AES-256-GCM. Disconnecting an app removes the connection from ClawLink. The split is documented in the trust center and on the security page.

Because the OAuth flow, the token storage, and the refresh loop run server side, a ClawLink connection completes in one browser approval without the user configuring an authorization server. The median completed connection took 32 seconds across 5,355 completed sessions from 2,073 people, measured 16 September 2026 (connection time report). On the execution side, 92.6 percent of 243,532 measured calls succeeded over the same window (tool execution report).

How do you verify a remote MCP server is safe?

Treat the server as part of your trust boundary. Check these before you rely on it:

1. The connection uses HTTPS.
2. The server publishes Protected Resource Metadata and validates token audience.
3. The client uses PKCE and a resource parameter.
4. The consent screen asks only for the scopes the tools require.
5. Provider credentials stay outside the model context and outside logs.
6. Disconnect and revocation are visible to the person who connected the app.
7. A denied request, an expired token, and a token for another server all fail as expected.

Item 7 is the one teams skip, and it is the one that proves validation exists rather than being assumed.

What changed in this review

Updated 16 September 2026. The authorization link now points at the 2026-07-28 specification revision. Added the RFC 8707 resource parameter and audience validation, Protected Resource Metadata discovery, client registration options, the 401/403/400 error table, the step-up scope flow, a credential-ownership comparison, and the ClawLink hosted-credential split with first-party connection and execution numbers.

FAQ

Keep reading