Your MCP server is an OAuth resource server: what it must do

Under the MCP 2026-07-28 specification, an MCP server that uses authorization acts as an OAuth resource server: it must publish OAuth 2.0 Protected Resource Metadata (RFC 9728), answer unauthenticated requests with a 401 whose WWW-Authenticate header points clients to that document, and validate every access token it receives, including the token's audience. The author notes that in the study he cited, about 40% of live remote servers asked for no authentication at all and only about 30% used OAuth, while the spec makes authorization optional — HTTP-based servers SHOULD follow the MCP authorization specification and stdio servers SHOULD NOT, taking credentials from the environment. Tokens never pass through: a server calling another API must obtain a separate token for it.

Your MCP server is an OAuth resource server: what it must do When I wrote about the Model Context Protocol MCP in MCP is in its Yahoo era https://pournasserian.com/ideas/mcp-is-in-its-yahoo-era , two numbers stayed with me: in the study I cited there, about 40% of live remote servers asked for no authentication at all, and only about 30% used OAuth. What surprised me, reading the MCP authorization rules closely, is how small the server’s share of the work is. As a resource server, it doesn’t issue tokens. It publishes one document, answers with the right challenge, checks every token it receives and keeps those tokens to itself. This is part 18 of my series on what an MCP server does under the 2026-07-28 specification, after subscriptions/listen in part 17 https://pournasserian.com/writing/mcp-2026-subscriptions-listen . The facts are as I read them in October 2026. In brief 1. Authorization is optional, but an HTTP server that uses it SHOULD follow the MCP authorization specification. A server on standard input and output stdio SHOULD NOT: it takes its credentials from the environment. 2. Your server is the resource server. It accepts and validates access tokens; an authorization server, bundled with it or separate, issues them. 3. It MUST publish Protected Resource Metadata, and its 401 points clients there. The challenge SHOULD name the scope the request needs. 4. Every token is validated, its audience included. A token issued for anything other than your server is refused. 5. Tokens never pass through. If your server calls another application programming interface API , it gets a separate token for it. Who does what The specification’s authorization page https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization makes authorization OPTIONAL. When you implement it, the rule depends on the transport part 7 https://pournasserian.com/writing/mcp-2026-transports covers the two standard ones : | Transport | Rule | |---|---| | HTTP-based, such as Streamable HTTP | SHOULD follow the MCP authorization specification | | stdio | SHOULD NOT; it retrieves credentials from the environment | | Any other | MUST follow established security practice for its protocol | The specification builds on a selected subset of established standards, among them OAuth 2.1, Client ID Metadata Documents, OpenID Connect Discovery and these five Requests for Comments RFCs : | Standard | Covers | |---|---| | RFC 6750 | Bearer tokens | | RFC 8414 | Authorization server metadata | | RFC 9728 | Protected Resource Metadata | | RFC 8707 | Resource indicators | | RFC 9207 | Issuer identification | A protected MCP server is a resource server: it accepts and validates access tokens but doesn’t issue them. The authorization server can be bundled with your MCP server or run separately Entra ID, Okta, Auth0, Keycloak and so on , and its internals are outside the specification. The client gets its token there, with Proof Key for Code Exchange PKCE , and sends it on every request: From the first 401 to a token Most of the flow belongs to the client and the authorization server: discovery, registration, the user’s sign-in and the token request. The client sends the user to sign in with PKCE and a resource parameter naming your server’s canonical Uniform Resource Identifier URI , then checks the issuer before it asks for the token. Your server’s part is the first two answers and the check at the end: What your server must do Duty 1: publish Protected Resource Metadata MCP servers MUST implement OAuth 2.0 Protected Resource Metadata RFC 9728 , and clients MUST use it to discover the authorization server. The document names your authorization server or servers and your scopes supported . Keep that list to the minimal set for basic functionality: more scopes are requested later, through step-up authorization. Duty 2: challenge correctly with a 401 A request without a valid token gets a 401 whose WWW-Authenticate header points to that document: HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer resource metadata="https://mcp.example.com/.well-known/oauth-protected-resource", scope="files:read" Servers SHOULD include scope in the challenge. Clients treat the challenged scopes as authoritative for the current operation, and those scopes may differ from scopes supported in any way. Duty 3: validate every token, including its audience Clients MUST send Authorization: Bearer <token on every HTTP request, and never in the query string. Servers MUST: - validate tokens as OAuth 2.1 section 5.2 describes; - check that the token was issued specifically for this server as its audience RFC 8707 ; - return 401 for an invalid or expired token. Duty 4: never pass tokens through Servers MUST only accept tokens valid for their own resources, and MUST NOT accept or transit any other tokens. If your server calls downstream APIs, get a separate token for them, for example through an on-behalf-of or token-exchange flow. Never forward the client’s token. The resource-server half in Python The official Python software development kit SDK , mcp 2.3.0, has most of the first three duties built in. You supply a TokenVerifier and AuthSettings ; MCPServer adds the 401, the metadata route and the audience check. My verifier is a labelled stand-in: python from mcp.server import MCPServer from mcp.server.auth.middleware.auth context import get access token from mcp.server.auth.provider import AccessToken, TokenVerifier from mcp.server.auth.settings import AuthSettings RESOURCE = "https://mcp.example.com/mcp" The audience of each demo token. The strings are labels, not credentials. DEMO TOKENS = { "demo-token-for-this-server": RESOURCE, "demo-token-for-another-api": "https://api.example.com", } class StandInVerifier TokenVerifier : """Stands in for a real verifier, which checks the signature, issuer and expiry.""" async def verify token self, token: str - AccessToken | None: if token not in DEMO TOKENS: return None return AccessToken token=token, client id="demo-client", scopes= "files:read" , resource=DEMO TOKENS token the audience it was issued for mcp = MCPServer "files", token verifier=StandInVerifier , auth=AuthSettings issuer url="https://auth.example.com", resource server url=RESOURCE, required scopes= "files:read" , validate token resource=True, refuse tokens issued for another resource , @mcp.tool def list files - str: """List the files the caller may read.""" token = get access token the token the middleware validated return f"{token.client id} may read: report.pdf, notes.txt" In the SDK, authorization applies only over HTTP stdio and the in-memory test client skip it , so I served it over Streamable HTTP inside one Python process, with no network. A request without a token got this: HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer error="invalid token", error description="Authentication required", resource metadata="https://mcp.example.com/.well-known/oauth-protected-resource/mcp" {"error": "invalid token", "error description": "Authentication required"} And the metadata, at the address in the challenge: { "resource": "https://mcp.example.com/mcp", "authorization servers": "https://auth.example.com" , "scopes supported": "files:read" , "bearer methods supported": "header" } What the runs showed: - Metadata. The SDK serves it at the well-known path with the endpoint’s path, /mcp , appended, and builds it from AuthSettings : required scopes becomes scopes supported . - Challenge. It points to the metadata but carries no scope , so the SDK doesn’t meet the SHOULD of duty 2 on its own. - Audience. The token my verifier marked as issued for https://api.example.com got the same 401, and the server logged why. Left unset, validate token resource makes 2.3.0 warn and skip the check; the setting’s description says 3.0 makes it the default, and that you set it to False when your verifier checks the token’s audience itself. - Header only. A token in the query string got a 401 too, because the SDK reads only the Authorization header. - Expiry. The middleware also refuses a token whose expires at has passed. - Success. The SDK client with the right token negotiated 2026-07-28, and the tool answered demo-client may read: report.pdf, notes.txt . Duty 4 is up to your own code. My advice: get access token hands your tool the client’s token, and that’s where it should stay. Method and caveats - Built from my guide’s chapter on authorization, written against the 2026-07-28 specification. - The Python sample ran against mcp 2.3.0 on 9 October 2026, served by the SDK’s own HTTP app inside one process, and the responses shown are what it returned. The notes on expiry, on the unset setting and on the in-memory client come from the package’s source and short probes. - This part covers the server’s first four duties. Step-up with 403, the status codes, the changes for clients and authorization servers, and authorization without sessions come next.