MCP Authentication & Authorization, Explained

The answer, and the trap

Securing an MCP integration comes down to answering, on every request, 'who is really asking, and are they allowed?' The correct pattern is delegated authentication: a remote MCP server sits behind OAuth 2.1, the client obtains an access token on behalf of the signed-in user, and the server acts as that user against the underlying system. Each request carries the user's own bounded authority, and the data layer, not the model, decides what that user may see or do.

The trap, and the wrong answer a question will dangle in front of you, is a shared credential: one long-lived API key or a broad service-account token that the server uses for everybody. That single identity can read and write everything, it cannot be attributed to a real user, and if it leaks, the attacker inherits all of it. Worse, the server becomes a confused deputy that will happily exercise its broad power on behalf of whoever, or whatever injected instruction, is driving the current turn.

Local (stdio) vs remote (HTTP) trust

MCP's authentication model depends entirely on how the server is reached, and the two transports sit on opposite sides of a trust boundary. Getting this distinction right is the foundation for everything else, because the safe pattern for one is dangerous when copied to the other.

The MCP authorization specification makes this explicit: stdio transports should not use the OAuth flow at all and instead retrieve credentials from the environment, while HTTP-based transports should implement the OAuth authorization spec. A local server trusts the user because it literally runs as them on their own machine. A remote server has no such implicit trust, it is exposed to the network and serves many users, so it must authenticate and authorize every single request.

OAuth 2.1 for remote MCP servers

The MCP authorization spec is built on OAuth 2.1 and assigns clear roles. The MCP server is an OAuth 2.1 resource server: it accepts and validates access tokens on protected requests. The MCP client is the OAuth client, making requests on behalf of the resource owner (the user). A separate authorization server interacts with the user, if needed, and issues the tokens. The server advertises its authorization server through Protected Resource Metadata, so the client can discover where to authenticate.

• The client makes an MCP request without a token; the server replies 401 Unauthorized with a WWW-Authenticate header pointing to its resource metadata.
• The client discovers the authorization server, registers or identifies itself, and runs the OAuth flow with PKCE to obtain an access token for the signed-in user.
• Crucially, the client includes a resource parameter (RFC 8707) naming the specific MCP server the token is for, so the token is minted for that audience and no other.
• The client then sends every subsequent request with an Authorization: Bearer header; the token is never placed in the URL query string.
• The server validates the token on every request, including that the token was issued specifically for it as the intended audience, and rejects anything else with a 401.

Token scoping and per-user delegation

Authenticating the caller is only half the job; the other half is making sure the token that results carries the least authority that still gets the work done. Two levers do this: per-user delegation (whose authority the token represents) and scope minimization (how narrow that authority is).

Per-user delegation means the token represents the signed-in user, so the downstream system automatically bounds the request to what that user is permitted to see. There is no shared super-identity to leak and no need for the server to re-implement access control, because the user's own permissions apply. Scope minimization means requesting only the specific scopes the operation needs; the MCP spec has the server advertise required scopes and encourages clients to request the minimum, escalating incrementally through a step-up flow only when a later operation genuinely needs more.

Secrets handling and agent-to-agent auth

Wherever credentials live, they must never live in the model's context. A prompt, a tool argument, a resource's text, and the conversation history are all things the model reads, can echo, and an injection can try to exfiltrate. The context window is not a vault. Authentication belongs in the transport layer, an Authorization header the model never sees, not in text the model handles.

• Never embed API keys, passwords, or long-lived secrets in prompts, tool arguments, system messages, or resource content.
• Carry credentials in the transport (bearer tokens on the HTTP request), out of band from the model's reasoning entirely.
• Store secrets in a secrets manager or environment, inject them at the server, and keep them off any path the model can read or emit.
• Prefer short-lived, rotatable tokens so a leaked credential expires quickly and unlocks little.

Agent-to-agent and server-to-server calls follow the same discipline rather than inventing a shortcut. When one agent or MCP server calls another on a user's behalf, it should carry a token scoped to that specific downstream service and audience, obtained through the proper flow, not forward whatever broad token it happens to hold. Forwarding a token minted for server A to server B is precisely the confused-deputy / token-passthrough mistake the audience-binding rules exist to prevent. Each hop authenticates as itself with a token intended for the next hop.

Authorization at the data layer, not the prompt

The single most important principle, and the one questions test hardest, is where the access-control decision is made. It must be made at the data layer, by code, using the authenticated user's identity, and it must be impossible for the model to override. A system prompt that says 'only show users their own records' is not authorization; it is a suggestion to a component that can be wrong, confused, or injected. Real authorization is a filter in the query and a permission check in the server that the model cannot talk its way past.

# Anti-pattern: authorization as a prompt instruction
system = "You are a support agent. Only reveal data belonging\n         to the current user. Never show other accounts."
# A prompt injection or model error can ignore this entirely.

# Correct: authorization enforced at the data layer
user = verify_access_token(request)      # who is really asking
rows = db.query(
    "SELECT * FROM tickets WHERE account_id = %s",
    user.account_id,                     # scoped by the DB, not the model
)
# The server acts AS the user; the model never sees other accounts'
# data, so it cannot leak what it was never given.

The reasoning is the same one behind least privilege everywhere: the model is the component you cannot fully trust under adversarial input, so it must never be the thing enforcing a must-hold access rule. When the MCP server acts as the authenticated user and the database filters by that user's identity, the model simply never receives data the user is not entitled to, and there is nothing for an injection to extract.