EXPLAINER

MCP Authorization (OAuth for MCP Servers)

protocolfreshness: volatilekey claims checked 2026-10-09

MCP authorization lets a client call a protected remote MCP server using OAuth 2.1: the server publishes protected-resource metadata, the client discovers the authorization server, requests a token bound to that server, and sends it as a bearer token on every request.

Short answer: In MCP, a protected HTTP server acts as an OAuth 2.1 resource server. Clients discover its authorization server through protected-resource metadata (RFC 9728), request tokens with the resource parameter (RFC 8707), and send Authorization: Bearer on every request. Servers must check the token was issued for them and must never pass tokens through. stdio servers take credentials from the environment instead.

What is it?

A remote MCP server often fronts private data. MCP borrows standard OAuth so the user logs in at an identity provider, approves access, and the client gets a token it presents to the server. The server tells clients where to log in, and the token is tied to that one server so it cannot be replayed elsewhere. A local server that runs on your machine does not use this flow; it just reads credentials from its environment.

Also known as: MCP OAuth, MCP authorization, MCP auth, OAuth for MCP servers, protected resource metadata, RFC 9728, RFC 8707 resource indicators, client ID metadata documents.

Technical definition

Based on MCP specification revision 2026-07-28: authorization is optional. Implementations on HTTP-based transports SHOULD conform; stdio implementations SHOULD NOT and instead retrieve credentials from the environment. The MCP server is an OAuth 2.1 resource server; the MCP client is an OAuth 2.1 client; the authorization server may be separate. (The specification cites OAuth 2.1 by its IETF draft number, i.e. it is still a draft.) Requirements stated include: servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728) and clients MUST use it to find the authorization server; authorization servers MUST provide RFC 8414 or OpenID Connect discovery; clients and authorization servers SHOULD support OAuth Client ID Metadata Documents, while Dynamic Client Registration (RFC 7591) is deprecated and kept for backward compatibility; clients MUST send the RFC 8707 resource parameter, naming the MCP server's canonical URI, in both authorization and token requests; clients MUST send the token in the Authorization: Bearer header on every HTTP request and MUST NOT put it in the query string; servers MUST validate that tokens were issued for them as audience, MUST respond 401 to invalid or expired tokens, and MUST NOT accept or transit other tokens (no token passthrough); authorization servers SHOULD return the RFC 9207 iss parameter and clients MUST validate it when present; refresh tokens MUST be kept confidential and clients MUST NOT assume they will be issued; insufficient-scope errors can trigger a step-up authorization flow. Earlier revisions differ in detail — check the revision your SDK implements.

Entity type: protocol · Freshness class: volatile.

When should I use it?

Use for remote MCP servers that expose user-specific or sensitive data. Not needed for a local stdio server that runs as the user.

Implementation patterns

  • Separate roles: the MCP server only validates tokens; a dedicated authorization server issues them.
  • Validate audience on every request; reject tokens minted for another resource.
  • Give each tool the narrowest scope and request more only when a call needs it (step-up).
  • For downstream APIs, have the MCP server obtain its own token for the downstream service rather than forwarding the client's.
  • Use stdio plus environment credentials for single-user local tools.

Technologies and frameworks

Commonly associated: OAuth 2.1 (IETF draft), RFC 9728 protected resource metadata, RFC 8414 / OIDC discovery, RFC 8707 resource indicators, RFC 9207 issuer identification, Client ID Metadata Documents, PKCE. Names are examples of what exists, not recommendations, and projects change quickly.

Practical guide

  1. Decide whether the server is remote (use this flow) or local stdio (use environment credentials).
  2. Choose an authorization server; confirm it supports discovery and, ideally, Client ID Metadata Documents.
  3. Publish protected-resource metadata for your server.
  4. Validate bearer tokens: signature, expiry, issuer and audience.
  5. Define scopes per tool; return insufficient-scope errors so clients can step up.
  6. Test with a real client, log denials without logging tokens, and review MCP Security Risks and Mitigations.

Common failure modes

  • Token passthrough: forwarding the client's token to an upstream API, which the specification forbids.
  • Skipping audience validation, so a token for one server works on another.
  • Putting tokens in URLs or logs.
  • Requesting one all-powerful scope at first login.
  • Treating protocol-level authorisation as enough: tool-level permissions and confirmation are still needed (MCP Security Risks and Mitigations).
  • Following an older tutorial that assumes Dynamic Client Registration is the default.

Troubleshooting

  • Client gets 401 and does not know where to log in — Serve protected-resource metadata and a WWW-Authenticate challenge pointing to it, per the specification.
  • Token accepted by the wrong server — Check the audience claim and the resource parameter the client sent.
  • Login loop with an enterprise identity provider — Check the issuer, redirect URIs and the application type used at registration.

Contrasted with

  • OAuth for AI Agents — That page covers an agent app calling a provider API such as Gmail; MCP authorization is the standard flow between an MCP client and an MCP server.
  • API Keys — Static keys are simpler but identify an app, not a consenting user, and cannot be scoped or revoked per user.

Questions this page answers

  • How does authorization work in MCP?
  • How do I add OAuth to an MCP server?
  • What is protected resource metadata in MCP?
  • Why does MCP use the resource parameter?
  • Do stdio MCP servers use OAuth?
  • What is token passthrough and why is it forbidden in MCP?

Typical goals: secure a remote MCP server with OAuth; understand how an MCP client logs in to a server; avoid MCP token-passthrough mistakes.

Sources and verification

Status: key claims checked on 2026-10-09 against the primary sources listed below; everything else is not independently verified. The claims under "Checked against primary sources" were compared with the linked pages on that date. Pages change, so re-check anything time-sensitive before relying on it.

Checked against primary sources (2026-10-09):

  • Authorization is optional; HTTP transports SHOULD conform, stdio SHOULD NOT and should take credentials from the environment.
  • MCP server = OAuth 2.1 resource server; MCP client = OAuth 2.1 client; OAuth 2.1 is cited as IETF draft draft-ietf-oauth-v2-1-13.
  • Servers MUST implement RFC 9728; clients MUST use it for authorization-server discovery.
  • Clients and authorization servers SHOULD support Client ID Metadata Documents; Dynamic Client Registration is deprecated and retained for backward compatibility.
  • Clients MUST send the RFC 8707 resource parameter in authorization and token requests; bearer token in the Authorization header on every request and never in the query string.
  • Servers MUST validate the token audience, return 401 for invalid or expired tokens, and MUST NOT accept or transit other tokens.
  • RFC 9207 iss: SHOULD be returned by authorization servers; clients MUST validate it when present.
  • Refresh tokens: clients MUST keep them confidential and MUST NOT assume they are issued.

Primary sources consulted:

Not independently verified:

  • That 2026-07-28 is still the newest revision when you read this.
  • The text of the discovery and scope-selection sub-pages (they could not be retrieved; only the overview page was read).
  • How much of this individual SDKs or hosted MCP clients implement.
  • Details of the step-up flow beyond its existence.

Freshness class: volatile — Products, versions, protocols, benchmarks, leaderboards, regulations and dates. Verify against the primary source before relying on specifics; re-review every 3 months.

Time-sensitive claims to verify before relying on them:

  • Which specification revision your SDK and clients implement.
  • Status of OAuth 2.1 and the Client ID Metadata Document draft (both cited as IETF drafts).
  • Deprecation status of Dynamic Client Registration.
  • Requirements differ between revisions (for example 2025-11-25 and 2026-07-28).

Further reading and canonical sources (not all checked):

  • MCP specification — Authorization (revision 2026-07-28) — modelcontextprotocol.io/specification/2026-07-28/basic/authorization
  • RFC 9728 — OAuth 2.0 Protected Resource Metadata — rfc-editor.org/rfc/rfc9728
  • RFC 8707 — Resource Indicators for OAuth 2.0 — rfc-editor.org/rfc/rfc8707
  • RFC 9207 — OAuth 2.0 Authorization Server Issuer Identification — rfc-editor.org/rfc/rfc9207