Expose an MCP server as an OAuth 2.1 protected resource: serve RFC 9728 Protected Resource Metadata and issue the 401 WWW-Authenticate challenge

Documented steps

1. Decide scope: authorization is OPTIONAL in MCP, SHOULD be used for HTTP-based transports, and SHOULD NOT be used for stdio (stdio servers should take credentials from the environment instead).
2. Implement OAuth 2.0 Protected Resource Metadata (RFC 9728) — this is a MUST for MCP servers. Serve the document at https://<host>/.well-known/oauth-protected-resource (and at the path-scoped variant /.well-known/oauth-protected-resource/{path} if your MCP endpoint has a path).
3. Include at least one entry in the document's authorization_servers array.
4. Populate scopes_supported with the MINIMAL set of scopes needed for basic functionality, not the full permission surface — additional scopes are meant to be obtained incrementally via step-up authorization.
5. On any MCP request without a valid token, respond HTTP 401 Unauthorized with a WWW-Authenticate header using the Bearer scheme and a resource_metadata parameter pointing at your PRM document, e.g. WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource".
6. Include a scope parameter in that challenge (SHOULD) naming the scopes required for the attempted operation, so the client can request least privilege on the first try.
7. Return HTTP 403 Forbidden for a valid token with insufficient scope or permissions, and HTTP 400 for a malformed authorization request — 401 is reserved for 'authorization required or token invalid'.
8. Require the Authorization: Bearer <token> header on EVERY HTTP request from client to server, and reject any attempt to pass the token in the URI query string.
9. Cross-check requirements at https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/index