CydentiCydenti
EN
|FR
Guide

MCP server security: authentication, OAuth and access control

MCP security starts with a simple fact: MCP servers connect AI clients to real tools and data, and they use real credentials to do it. This guide explains how MCP authentication and MCP OAuth work, the main risks, and a checklist you can apply today. New to the terms? See MCP and MCP server.

Why MCP servers are an identity problem

To read a mailbox or query a CRM, an MCP server holds a credential: an API key, an OAuth token or a service account. That credential is a non-human identity. Anyone who controls the server, or tricks it, can use those rights. So most of MCP security is identity security: what the credential can reach, who owns it, and when it was last used.

Local (STDIO) vs remote (HTTP) MCP servers

  • Local (STDIO): the server runs as a process on the user's machine. The MCP specification says STDIO implementations SHOULD NOT use the MCP authorization flow and should retrieve credentials from the environment instead. In practice that often means keys in environment variables or config files, so protect the host and those files.
  • Remote (HTTP): the server runs as a network service. Authorization is optional in MCP, but HTTP implementations SHOULD follow the authorization specification. This is where OAuth applies.

How MCP authorization works (OAuth 2.1 in 6 steps)

The MCP authorization specification builds on the OAuth 2.1 draft. The MCP server acts as an OAuth 2.1 resource server.

  1. 1Challenge. Typically, the client calls without a token and receives a 401 with a WWW-Authenticate header pointing to the server's metadata.
  2. 2Discovery. MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728), which names the authorization server. Clients MUST use it to find that server.
  3. 3Registration. The client gets a client ID: preferably through a Client ID Metadata Document, or by pre-registration. Dynamic Client Registration is deprecated and kept for backwards compatibility.
  4. 4Authorization. The user signs in. The client uses PKCE and MUST send the resource parameter (RFC 8707) naming the MCP server. It checks the iss value in the response (RFC 9207).
  5. 5Token use. The token goes in the Authorization: Bearer header on every request, never in the query string.
  6. 6Validation. The server MUST check that the token was issued for it (audience). A missing or invalid token gets a 401. A valid token without the right scope gets a 403 insufficient_scope, and the client can ask for more scope through step-up authorization.

Top MCP security risks

The MCP project lists these in its security best practices:

  • Token passthrough: a server accepts a client's token without checking it was issued for the server, then forwards it to a downstream API. The spec forbids it.
  • Confused deputy: an MCP proxy server using a static client ID with a third-party authorization server can let a malicious client obtain an authorization code without the user's real consent.
  • Over-broad scopes: broad scopes such as files:* or admin:* raise the impact of any stolen token.
  • Local server compromise: a local server runs with the user's rights and can read files and keys on that machine.
  • Static keys in config files: long-lived keys get copied, synced and leaked.
  • Unowned servers: a test server keeps live credentials after its owner moves on.
  • Tool poisoning and prompt injection: malicious tool descriptions or tool output push the model to misuse its access. OAuth does not prevent this.

MCP server security checklist

  1. 1Keep an inventory of every MCP server, local and remote, with a named owner.
  2. 2Map the credential behind each server and what it can reach.
  3. 3For remote servers, implement MCP authorization: OAuth 2.1, PKCE and Protected Resource Metadata.
  4. 4For local servers, keep credentials out of shared config files and source control.
  5. 5Validate the token audience on the server. Never pass client tokens through.
  6. 6Request minimal scopes; use step-up for sensitive actions.
  7. 7Prefer short-lived tokens to static keys; keep the remaining secrets in a vault.
  8. 8Send tokens only in the Authorization header, over TLS.
  9. 9Review tool descriptions before install; treat tool output as untrusted.
  10. 10Review activity regularly and remove unused servers, keys and OAuth grants.

Where Cydenti fits

Cydenti is a non-human identity security platform, not an MCP gateway. It does not sit in MCP sessions, issue runtime credentials or rotate secrets. It reads Microsoft 365 / Entra ID, Google Workspace and Salesforce through read-only APIs, and can show the service accounts and OAuth apps that MCP servers use, when those identities are visible in one of these apps. The Identity Graph and blast radius analysis show what each identity can reach, and fixes for excessive or unused rights run automatically, following the policies you set. Dedicated MCP views are in preview: see MCP security. Cydenti complements your IAM, PAM and gateway tools.

Find the identities behind your AI tools.

Start my free Audit Flash

Up to 3 SaaS apps, read-only, no credit card, first inventory usually within a week.

FAQ

Is authentication required in MCP?

No. Authorization is optional in the MCP specification. Remote HTTP servers should implement it. Local STDIO servers should get credentials from the environment instead.

What OAuth version does MCP use?

MCP authorization is based on the OAuth 2.1 draft, with PKCE, Protected Resource Metadata (RFC 9728) and Resource Indicators (RFC 8707).

What is token passthrough in MCP?

An MCP server accepting a token that was not issued for it and forwarding it to another API. The MCP specification forbids it: servers must accept only tokens issued for them.

What is the difference between a 401 and a 403 in MCP?

A 401 means the token is missing or invalid. A 403 with insufficient_scope means the token is valid but lacks a scope; the WWW-Authenticate header names the scope needed, and the client can request it through step-up authorization.

Are local MCP servers safer than remote ones?

Not automatically. They avoid network exposure, but they run with the user's rights and often rely on static keys stored on the device.

Does OAuth stop prompt injection?

No. OAuth controls who can call a server and with which scopes. Tool poisoning and prompt injection need separate controls: reviewing tools, limiting scopes and treating tool output as untrusted.

Last reviewed against the MCP specification: 4 November 2026.

MCP security: authentication, OAuth and authorization