MCP Authentication and Authorization Explained
A production-focused guide to authenticating MCP clients and authorizing users, tools, resources, tenants, and downstream actions.
A production-focused guide to authenticating MCP clients and authorizing users, tools, resources, tenants, and downstream actions.
Remote MCP servers are protected resources, not authorization servers by default.
Authentication proves who is making an MCP request. Authorization decides what that identity may do. Production systems need both, plus object, tenant, tool, and downstream policy.
The current MCP authorization specification applies to HTTP-based transports and builds on OAuth concepts. Local STDIO deployments use process and host security rather than the same network flow.
TL;DR
- Remote MCP servers are protected resources, not authorization servers by default.
- Clients discover authorization-server information through protected-resource metadata.
- Access tokens must be intended for the MCP resource and sent in the Authorization header.
- Servers must validate tokens, scopes, audience, expiration, and request authorization.
- Tool discovery and protocol capabilities do not grant user permission.
Authentication versus authorization
Authentication answers: which user, service, or client is represented by this request?
Authorization answers: may that principal use this server, invoke this tool, access this object, and perform this side effect now?
A valid token is not permission to do everything the server exposes.
The protected-resource model
A remote MCP server acts as an OAuth protected resource. It can advertise protected-resource metadata that points clients toward the appropriate authorization server.
The authorization server handles user or client authorization and issues access tokens. The MCP server validates tokens presented for its resource.
Keeping these roles separate allows an organization to use an established identity platform rather than embedding login behavior in every MCP server.
A simplified remote flow
- The client contacts an MCP endpoint without a valid token.
- The server returns an authorization challenge and protected-resource metadata location.
- The client discovers the authorization server.
- The client performs the supported OAuth flow.
- The authorization server issues a resource-bound, scoped access token.
- The client sends the token in the HTTP Authorization header.
- The MCP server validates the token and authorizes the requested operation.
Do not place access tokens in query strings. URLs leak through logs, analytics, browser history, and referrers.
Validate the token for this server
The MCP server should validate signature or introspection result, issuer, audience or resource indicator, expiration, not-before time, and required scopes.
Reject tokens intended for another service. Token passthrough is dangerous because it can confuse audiences and extend authority beyond the intended resource.
Scope design
Scopes should express coarse capability boundaries such as orders.read or tickets.write. They should not be the only authorization layer.
After a scope check, enforce tenant membership, object ownership, business rules, amount limits, environment, and human approval.
| Layer | Example question |
|---|---|
| Token audience | Is this token intended for the order MCP server? |
| Scope | Does it include orders.read? |
| Tenant | Is the user in the order organization? |
| Object | May the user read order 4812? |
| Business rule | Is the refund window open? |
| Approval | Did the user confirm the refund amount? |
User identity and service identity
Some operations act on behalf of a user; others use a service principal. Record which model applies and avoid silently switching.
For delegated user actions, preserve the user identity through the server and downstream authorization. For background jobs, use a dedicated service identity with tightly scoped permissions.
Never trust a model-supplied user_id argument as identity.
Local STDIO security
STDIO does not use the same OAuth network flow. The host controls which executable launches and what environment, filesystem, and credentials it inherits.
Use explicit executable paths, minimal environment variables, restricted working directories, sandboxing, and reviewed server packages. Local execution can have more machine access than a remote service.
Consent and high-impact tools
Authorization determines whether an action is permitted; consent determines whether the user intends it now. A user may have refund permission but still deserve a preview and confirmation before execution.
Record approval with the exact tool, arguments, resource, time, and user. Do not reuse vague consent from an earlier unrelated action.
Multi-tenant servers
Derive tenant context from trusted identity and routing, not model arguments. Partition caches, logs, resources, and downstream credentials. Test cross-tenant identifiers deliberately.
A tool list may also be tenant-specific. The host should not assume every authenticated user sees the same catalog.
Common failures
- Accepting any valid token regardless of audience.
- Passing one service token through several downstream systems.
- Using broad scopes as the complete policy.
- Taking user or tenant identity from tool arguments.
- Storing tokens in URLs or logs.
- Treating local servers as automatically trusted.
- Confusing capability discovery with authorization.
My Take
MCP does not create a new security universe. It exposes familiar identity and authorization mistakes through a model-facing surface, where ambiguity and automation increase the consequences. Keep the identity chain explicit from user to host to server to backend.
Continue learning
Review [MCP Security and Permissions](/mcp-security-and-permissions/) and [Tool Permissions and Least Privilege](/tool-permissions-and-least-privilege/).
