MCP Server Authentication Discovery: 401, WWW-Authenticate, and Metadata

Remote MCP authentication has two separate questions: how does a client discover which authorization server to use, and how does the MCP server validate the token it receives? Many integration failures happen before a tool call because discovery is incomplete, the resource identifier is wrong, or the client cannot interpret a 401 response.

The protected resource is the MCP server

In the MCP authorization model, the remote MCP server is the protected resource. It is not the authorization server that issues tokens. The client asks the resource for the authorization-server location, obtains a token for the MCP resource, and presents that token to the MCP server. Keeping those roles separate prevents a server from treating an upstream access token as if it were automatically valid for every downstream API.

What a 401 challenge should communicate

When the MCP server returns 401 Unauthorized, the WWW-Authenticate header can include a resource_metadata URL. The current authorization specification also describes a scope parameter that can tell the client which scopes are needed for the current request. The header is discovery guidance, not a place for credentials, user data, or a pre-authenticated URL.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource", scope="files:read"

Protected Resource Metadata is a contract

The metadata document tells the client which authorization servers protect the MCP resource. The current specification requires an authorization_servers field with at least one authorization server. A server can expose the document at a well-known URL or make its location available through the 401 challenge. Clients are required to support both discovery mechanisms and use the challenge URL when present.

• Serve the metadata over HTTPS in production.
• Use the canonical MCP resource URI consistently in metadata, authorization requests, token requests, and server validation.
• Publish only the authorization-server locations and scopes that the client needs to discover the flow.
• Test the endpoint without an access token and test the exact path used by the MCP endpoint.

Why resource indicators matter

The authorization specification requires clients to include a resource parameter in authorization and token requests. That parameter binds a token to the MCP server it is intended for. The server must validate that the presented token was issued for it and must reject tokens intended for another resource.

Debug discovery in layers

• Transport: confirm DNS, TLS, and the MCP endpoint respond at the expected URL.
• Challenge: confirm an unauthenticated request returns 401 and a useful WWW-Authenticate header when that mechanism is used.
• Metadata: fetch the advertised document and verify authorization_servers and its content type.
• Authorization server: verify the issuer metadata and token endpoint according to the supported discovery mechanism.
• Resource binding: confirm the token audience or resource matches the MCP server before a tool executes.
• Scopes: test missing, valid, and excessive scopes without logging the token value.

What not to put in logs

Do not log bearer tokens, authorization codes, refresh tokens, client secrets, or full authorization URLs containing sensitive state. Log the outcome class, issuer host when safe, resource identifier class, scope names if they are non-sensitive, and a stable request correlation identifier. Redact query values before a URL enters an error or telemetry payload.

TrackMCP can show server-boundary authorization failures and the tool traffic that follows a successful connection. It does not replace an identity provider audit log, and it does not see a private client redirect or the user's consent screen unless your controlled integration emits that event.