MCP OAuth Explained: How MCP Authorization Works

Which revision this covers

This post follows the MCP authorization spec, revision 2026-07-28. That was the latest revision on modelcontextprotocol.io on 5 October 2026. Where it differs from the previous revision, 2025-11-25, the text says so.

Authorization is optional in MCP. An HTTP server that adds it should follow this spec. A stdio server should not: it reads credentials from its environment. Remote vs local MCP servers explains the two transports, and Model Context Protocol covers the protocol as a whole.

Who is who in MCP authorization

The spec maps MCP onto standard OAuth roles.

The building blocks

OAuth 2.1

OAuth 2.1 is an IETF draft that folds OAuth 2.0 and its later security fixes into one document. It drops the implicit grant and the password grant, and it requires PKCE for the authorization code flow. The MCP spec says authorization servers must implement it.

PKCE

PKCE (Proof Key for Code Exchange) makes a stolen authorization code useless. The client invents a secret and sends a hash of it with the sign-in request. It reveals the secret when it trades the code for a token.

MCP clients must use PKCE, with the S256 method whenever they are able to. They must also check the auth server's metadata first. If code_challenge_methods_supported is missing, the client must stop.

Protected resource metadata (RFC 9728)

This is how the client finds the auth server. The MCP server must publish a JSON document whose authorization_servers field lists at least one. It must point to that document in at least one of two ways, and clients must support both:

• a resource_metadata URL in the WWW-Authenticate header of a 401 response
• a well-known path, /.well-known/oauth-protected-resource, at the root or with the MCP endpoint's path appended

The client then fetches the auth server's own metadata, through RFC 8414 or OpenID Connect Discovery. It must reject a document whose issuer does not match the URL it asked.

Resource indicators (RFC 8707)

The client must send a resource parameter that names the MCP server, for example https://mcp.example.com/mcp. It goes on both the authorization request and the token request, even if the auth server ignores it.

The server does its half by rejecting any token that was not issued for it. Together, the two mean a token for server A should be refused by server B. The spec adds a caveat: the binding only holds when the auth server supports resource indicators.

Client registration

The auth server needs to know which app is asking. The spec gives three methods.

A client that supports all three should try them in that order. If none works, it asks the user to enter client details.

DCR was already optional in 2025-11-25, which described it as a backwards-compatibility option. The 2026-07-28 revision formally deprecates it. Under the spec's new lifecycle policy, a deprecated feature stays for at least twelve months.

CIMD suits MCP because most clients and servers have never met. A URL-based ID lets an auth server check a client's name and redirect URIs with no sign-up step.

No token passthrough

An MCP server usually calls another API on your behalf. The spec keeps the two hops apart:

• The server accepts only tokens issued for it.
• It must not pass the client's token to the upstream API.
• Upstream, it uses a separate token issued by that API's authorization server.

MCP security best practices covers what goes wrong when a server ignores this.

The MCP OAuth flow, step by step

Three details from the spec text:

• The issuer check is new in 2026-07-28. Auth servers should add an iss parameter to the redirect (RFC 9207). The client must compare a returned iss with the issuer it recorded before the redirect, and it must do so before sending the code anywhere. If the metadata says the server supports iss and none comes back, the client rejects the response. This blocks mix-up attacks, where one auth server tricks a client into handing over a code issued by another. PKCE alone does not stop them.
• Step-up scopes. A server can answer a call with 403 and insufficient_scope, naming the scopes that call needs. The client re-authorizes with those added to what it already asked for, so first-time consent stays small. This was already in 2025-11-25.
• The token travels in a header. Every request carries it in Authorization. It must never go in the URL query string.

MCP authentication checklist

If you build an MCP server:

• Publish protected resource metadata that lists at least one authorization server.
• Return 401 with a resource_metadata URL. Add a scope value that covers only what the request needs.
• Validate each token's audience. Answer 401 for anything invalid or expired.
• Never forward the client's token upstream.
• If you proxy a third-party API with one static client ID, get consent per client before you redirect.
• Keep scopes_supported to the minimum, and use step-up challenges for the rest.

If you build or choose an MCP client:

• Use PKCE with S256. Refuse auth servers that do not advertise PKCE.
• Send resource on the authorization request and the token request.
• Support CIMD, and fall back to DCR only where the auth server lacks it.
• Check iss before you redeem the code.
• Store client credentials per auth server, keyed by its issuer. The 2026-07-28 revision spells this out as a MUST.
• Keep tokens out of URLs.

How PopMCP handles the two hops

Connecting an AI client to a business tool takes two authorizations. The AI client needs access to the MCP server. The MCP server needs access to the provider, such as Shopify or Xero. PopMCP keeps the two apart.

For the first hop, the endpoint https://app.popmcp.com/mcp runs the discovery flow described above. It serves protected resource metadata (RFC 9728) and authorization server metadata (RFC 8414). It uses the authorization code flow with PKCE S256, and clients register through DCR. You paste the URL into your client, sign in with Google or an email code, and tick the connectors that client may reach. There is no token to copy from a dashboard.

For the second hop, the provider credential never reaches the AI client. If a laptop or a client config file leaks, the Shopify or Xero credential is not in it.

Where it stops short of the current spec:

• PopMCP negotiates MCP revisions up to 2025-11-25. It does not implement 2026-07-28.
• It does not support Client ID Metadata Documents. Registration is DCR, the method 2026-07-28 deprecates but keeps for backwards compatibility.
• It speaks Streamable HTTP only. The older SSE transport is not supported.
• There is no screen for withdrawing one client's grant. To cut access you remove the member, disconnect the connector, or run consent again with fewer connectors ticked.

The MCP server catalog lists the providers you can connect this way.