Understanding Authorization in MCP

Learn how to implement secure authorization for MCP servers using OAuth 2.1 to protect sensitive resources and operations.

Adapted from Understanding Authorization in MCP. Normative detail: Authorization specification.

OAuth flows apply primarily to HTTP-based (remote) transports.

Executive summary

Authorization is optional but strongly recommended for user-specific data, auditable actions and enterprise access control. MCP follows OAuth 2.1 conventions with Protected Resource Metadata (RFC 9728) discovery — not a proprietary auth scheme.

When to use authorization

Use authorization when:

• The server accesses user-specific data (email, documents, databases)
• You must audit who performed which actions
• APIs require user consent
• Enterprise environments demand strict access control
• You need per-user rate limiting or usage tracking

Local (stdio) vs remote

Transport	Typical auth approach
stdio (local)	OS user + env credentials / embedded libraries; OAuth browser flows are often unnecessary
Streamable HTTP (remote)	OAuth 2.1 between client and remotely hosted server

High-level flow

1. Client connects → server returns 401 with WWW-Authenticate pointing at Protected Resource Metadata (PRM).
2. Client fetches PRM (resource URL, authorization servers, scopes).
3. Client discovers authorization-server metadata (OIDC / RFC 8414).
4. Client registers (dynamic or pre-registered) and completes the authorization code flow with PKCE.
5. Client retries MCP requests with a bearer access token.

Example challenge:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="mcp",
  resource_metadata="https://your-server.com/.well-known/oauth-protected-resource"

Example PRM document:

{
  "resource": "https://your-server.com/mcp",
  "authorization_servers": ["https://auth.your-server.com"],
  "scopes_supported": ["mcp:tools", "mcp:resources"]
}

Enterprise extensions

Beyond core auth, see:

• Authorization extensions overview
• OAuth client credentials (machine-to-machine)
• Enterprise-managed authorization

Negative cases

Risk	Mitigation
Skipping PKCE	Require PKCE for public clients
Over-broad scopes	Least privilege; document scopes
Token in logs / LLM context	Never echo tokens to models or stdout
Accepting tokens for the wrong audience	Validate aud / resource indicators
Local server pretending OAuth is “done”	Still sandbox filesystem and secrets

Key takeaways

• Prefer OAuth 2.1 + PRM for remote MCP.
• Stdio servers lean on local credentials — still least-privilege the tools.
• Validate audience and scopes on every request.

What to do next

Continue with Security best practices.