How does MCP authentication work?

By Identra · Updated July 12, 2026

MCP authentication is how Model Context Protocol clients prove their identity, and their user's authorization, to MCP servers. The current specification (2025-11-25) makes authorization optional and HTTP-specific, building on OAuth 2.1 with mandatory PKCE, resource indicators, and audience validation, so each MCP server only accepts tokens issued specifically for it.

Key numbers

1,862 MCP servers were found exposed directly to the internet in a July 2025 scan (Knostic, 2025)
119 of 119 exposed MCP servers sampled for manual verification allowed access to tool listings without any authentication (Knostic, 2025)

Why MCP needs its own authentication story

The Model Context Protocol standardizes how AI agents connect to tools and data, which means a single MCP server often sits in front of email, code repositories, databases, or payment systems. Every one of those connections is a credential an attacker would love to hold, and the broader risks are covered in our MCP security entry. Authentication is the first control in that chain: it decides which client may talk to the server at all, and whose authority each request carries.

Early MCP deployments mostly ran locally over STDIO and inherited whatever credentials sat in environment variables, a pattern with all the weaknesses described in API key security. As remote MCP servers became the norm, the ecosystem needed real authorization. Researchers at Knostic found 1,862 MCP servers exposed directly to the internet in mid 2025, and every one of the 119 servers they manually verified allowed unauthenticated access to its tool listings. That gap between adoption and authentication is exactly what the current specification tries to close.

How the MCP authorization flow works

The MCP specification (2025-11-25 revision) defines an optional authorization framework for HTTP transports on top of OAuth 2.1; STDIO transports sit outside it and retrieve credentials from the environment. The MCP server acts as an OAuth resource server, the MCP client acts as an OAuth client, and a separate authorization server issues tokens. The flow is designed so a client can discover everything it needs at connect time, which matters because agents routinely connect to servers they have never seen before, a dynamic that also drives AI agent sprawl.

The client calls the MCP server without a token and receives HTTP 401 with a WWW-Authenticate header pointing at protected resource metadata (RFC 9728).
That metadata names the authorization server, and the client fetches its capabilities via authorization server metadata (RFC 8414).
The client identifies itself with a pre-registered client ID where one exists, with a Client ID Metadata Document (an HTTPS URL serving its metadata) where the authorization server supports it, or through Dynamic Client Registration (RFC 7591) as a backwards-compatible fallback.
The client runs the OAuth 2.1 authorization code flow with PKCE, including a resource parameter (RFC 8707) that names the exact MCP server the token is for.
The client sends the access token as a Bearer header on every request, and the server validates that the token was issued specifically for it before serving anything.

What the specification mandates

The 2025-11-25 authorization spec is deliberately strict about the failure modes that burned early deployments. Several requirements are hard MUSTs, and together they target token replay and the confused deputy problem, where a privileged intermediary is tricked into using its authority for the wrong caller.

PKCE is mandatory for MCP clients, closing off authorization code interception and injection.
Clients must send the RFC 8707 resource parameter in both authorization and token requests so tokens are audience bound to one server.
Servers must validate that inbound tokens were issued for them specifically and must reject everything else.
Token passthrough is explicitly forbidden: an MCP server must never forward the client's token to a downstream API, it must obtain its own.
Tokens must travel in the Authorization header, never in URL query strings, and all authorization endpoints must use HTTPS.
Authorization servers should issue short lived access tokens and must rotate refresh tokens for public clients.

Where MCP authentication still falls short

OAuth 2.1 answers the question of whether a client may call a server. It does not answer who the agent is. A token minted for a user session says nothing durable about the agent acting on that user's behalf, which is the core gap explored in AI agent identity. When one agent invokes another through a chain of MCP servers, the original user context can blur or disappear entirely, the delegation problem covered in AI agent delegation.

Scope granularity is another open issue. Many MCP servers request broad scopes at consent time, recreating the over-permissioned integrations described in OAuth app risk and violating least privilege from day one. STDIO servers sit outside the spec entirely and still pull long lived credentials from local environments, feeding the same hygiene problems as any secrets management program. And nothing in the spec inventories which MCP servers employees have connected in the first place, so unauthorized connections become another form of shadow AI.

How to secure MCP authentication in practice

Treat every MCP server and every client connection as a non-human identity with an owner, an inventory record, and a review cadence. The spec gives you strong primitives; operational discipline determines whether they hold up.

Upgrade to the current specification: require OAuth 2.1 with PKCE and resource indicators, and retire servers that accept static bearer secrets.
Never expose an unauthenticated MCP server to the internet, even for testing; scanners find them in hours.
Scope tokens narrowly per server and per tool, and prefer short lifetimes over long lived grants, moving toward zero standing privileges.
Verify audience validation is actually enforced, not just supported, on every server you run.
Monitor token usage at runtime for anomalous tool calls and replayed tokens, since stolen MCP tokens behave like any other session hijacking artifact.
Maintain a live inventory of MCP servers and the identities behind them, and fold it into your broader agent governance program.

How Identra thinks about it

Identra views MCP authentication as necessary but not sufficient. OAuth 2.1 with PKCE and audience binding solves transport-level trust, yet the enterprise problem starts after the token is issued: which agent holds it, what it does with the access, and whether anyone can see that activity. Every MCP connection mints a new non-human identity, and most organizations cannot enumerate theirs today. We believe MCP tokens should be inventoried, attributed to an owning human and agent, scoped to least privilege, and watched at runtime as part of runtime identity security, because a perfectly authenticated agent with excessive access is still an incident waiting to happen.

Go deeper: The Non-Human Majority

Frequently asked questions

Is authentication required by the MCP specification?

Authorization is optional in the MCP specification. When implemented over HTTP transports, it should follow the spec's OAuth 2.1 based flow; STDIO transports are told to pull credentials from the environment instead. In practice, any remote MCP server handling real data needs authentication, because exposed unauthenticated servers are actively scanned for and discovered.

What is the difference between MCP authentication and MCP authorization?

Authentication proves who the client and user are, while authorization decides what the resulting token may do. The MCP spec bundles both into one OAuth 2.1 flow: the authorization server authenticates the user, identifies the client, and issues an access token scoped and audience bound to a specific MCP server, which the server validates on every request. No single step proves server, client, and human identity simultaneously.

Why does MCP require the OAuth resource parameter?

The RFC 8707 resource parameter binds each token to the exact MCP server it was requested for. Without it, a token issued for one server could be replayed against another, and a malicious server could harvest tokens intended for other resources. MCP clients must send it in both authorization and token requests, and servers must reject tokens not issued for them.

How do agents authenticate to local STDIO MCP servers?

The OAuth based authorization flow only covers HTTP transports. STDIO servers, which run as local processes, retrieve credentials from the environment, typically API keys or tokens in config files and environment variables. That places them outside the spec's protections, so the same rotation, scoping, and inventory discipline used for any machine credential applies.