MCP Authentication
Authentication is the first question an MCP deployment has to answer: who is calling? The Model Context Protocol handles it at the transport layer, with an OAuth flow for HTTP servers and static credentials for STDIO ones. In practice most servers still authenticate with a shared API key, and a shared key is exactly the thing you cannot attribute, scope, or revoke per person.
This page covers how authentication works in MCP, where the common patterns fall short, and how per-person scoped tokens fix the gap, so every agent and every teammate carries its own revocable credential instead of a copy of one master key. It pairs with the broader AI agent security and MCP security references.
How authentication works in MCP
MCP defines authentication at the transport, not in the tool layer. For HTTP transports, the specification describes an OAuth 2.0 flow: the client obtains an access token and presents it with each request. The 2025-11-25 revision tightened this by mandating RFC 8707 Resource Indicators, which bind a token to the specific server it was issued for so it cannot be replayed against a different one. For STDIO transports, where the server runs as a local child process, authentication is usually a static credential, an API key or service-account token, passed through an environment variable or config file.
That flexibility is also the gap. Conformance to the OAuth flow is uneven across clients, so many real deployments default to static keys. A 2026 survey found that 53% of production MCP servers rely on static API keys, only 8.5% use OAuth, and the remaining 38.5% use no authentication at all. The protocol gives you a good option; it does not make you take it.
Authentication is not authorisation
Authenticating a caller proves identity. It does not decide what that identity is allowed to do once it is through the door. An authenticated agent with a valid token can still call delete_repository, issue a refund, or run a destructive query, because authentication says who, not what. Closing that second gap is authorisation and policy: evaluating each tool call against rules before it runs. Strong authentication is necessary and not sufficient; you need both, and they are different controls.
Why shared API keys are the weak point
The default pattern, one API key pasted into everyone's config, fails on every operational axis that matters:
- No identity. Every call arrives as the same key, so you cannot tell which person or agent made it, and your audit trail cannot attribute anything.
- No per-person scope. The key carries the union of everything it can reach. You cannot give one teammate read-only and another full access without minting and managing separate keys by hand.
- No clean revocation. When someone leaves, rotating the shared key breaks everyone at once. So it rarely gets rotated, and access outlives the laptop it was set up on.
- It lives on endpoints. The real credential sits in dotfiles and local configs, where it leaks through screenshares, backups, and committed files.
Per-person scoped tokens
The fix is to stop handing out the upstream credential at all. Put a gateway in front of your servers, hold each upstream key in it, encrypted at rest, and give every person and every agent its own scoped grant token. Each caller authenticates to the gateway with their grant; the gateway injects the real credential only when a call is authorised. The upstream key never lands on a laptop.
That single change resolves the shared-key failures at once: every call is attributable to an identity, access is scoped per grant, and offboarding is one revocation that leaves everyone else untouched. PolicyLayer issues these per-person grants as part of routing MCP traffic, so authentication, scoping, and audit come from the same place you enforce policy. See how a team rolls this out across every seat.
How to authenticate MCP access safely
- Prefer OAuth where the server supports it. Scoped, short-lived, resource-bound tokens beat long-lived keys.
- Never distribute the upstream key. Hold it once, behind a gateway, and inject it on authorised calls.
- Issue a grant per identity. Each person and agent gets its own token, never a shared one.
- Make every call attributable. Log who authenticated, what they called, and the decision.
- Revoke per grant. Offboarding should be one revocation, with no key rotation and no disruption to others.
- Pair authentication with policy. Authentication proves who; policy bounds what they can do.
Frequently asked questions
What is MCP authentication?
MCP authentication is how a client or agent proves its identity to an MCP server before it can call tools. The Model Context Protocol handles this at the transport layer: HTTP transports can use an OAuth flow, while STDIO transports typically rely on static credentials such as API keys or service-account tokens passed through the environment. Authentication establishes who is calling; it does not, on its own, decide what that caller is allowed to do.
Does MCP support OAuth?
Yes. The MCP specification defines an OAuth 2.0 flow for HTTP transports, and the 2025-11-25 revision mandates RFC 8707 Resource Indicators so that a token issued for one server cannot be replayed against another. Client conformance is still uneven, so in practice many deployments fall back to static keys. Treat cross-server token reuse as a present risk until every client in your stack honours resource indicators.
How do I authenticate to an MCP server?
It depends on the transport. For an HTTP server that implements the OAuth flow, your client completes the authorisation handshake and receives a scoped access token. For a STDIO server, you usually supply an API key or token through an environment variable or config file. The cleaner pattern for a team is to authenticate once to a gateway with a per-person token, and let the gateway hold and inject the upstream credentials, so individual API keys never land on laptops.
API key or OAuth for MCP?
OAuth is preferable where it is available: tokens are scoped, short-lived, and bound to a resource, so a leak is contained and expires. Static API keys are simpler but long-lived, broadly scoped, and shared, which makes them hard to rotate and impossible to attribute to a person. A 2026 survey found 53% of production MCP servers rely on static keys and only 8.5% use OAuth. Where you are stuck with keys, keep them off endpoints and behind a gateway that issues per-person grants instead.
How do I secure MCP credentials?
Stop distributing the upstream key. Hold it in one place (a gateway), encrypt it at rest, and inject it only when a call is authorised, so agents and laptops only ever hold a scoped grant token, never the real credential. Give each person and agent their own grant, log every call against it, and revoke a single grant without rotating the shared key or disrupting anyone else.
Can I give each person their own MCP access?
Yes, with a gateway in front of your servers. Each person and each agent connects with its own scoped grant token rather than a shared key. Access is granted per identity, every call is attributable, and offboarding is a single revocation. The upstream credential stays in the gateway and is never copied into a personal config.