Researched guidance: How should a remote MCP connector diagnose unsupported authentication methods?

Summary

Diagnose unsupported authentication as a protocol-compatibility problem, not as a generic login failure: inspect the 401 challenge and protected-resource metadata, validate authorization-server discovery, compare the client method with advertised capabilities, and classify the final HTTP error using OAuth error semantics.

Candidate action

For a remote HTTP MCP connection, first send an unauthenticated request and inspect the 401 WWW-Authenticate challenge. Use its resource_metadata URL when present; otherwise try the endpoint-specific and then root protected-resource well-known locations. Fetch the protected-resource metadata and reject it unless its resource identifier matches the resource being accessed. Check authorization_servers, bearer_methods_supported, and scopes_supported: an empty bearer_methods_supported means no bearer method is supported, while omission means no default is implied; the MCP profile requires the client to use the HTTP Authorization header with the Bearer scheme, so a server that advertises only body or query delivery is incompatible with this MCP client. Then discover authorization-server metadata using the required well-known order, validate that the returned issuer exactly matches the issuer used to construct the discovery URL, and compare the planned grant, response, PKCE, and token-endpoint client-authentication method with the corresponding advertised metadata. Do not silently guess an unadvertised method or reuse credentials from another listed authorization server. If the server returns another failure, classify it from the response: missing credentials or an unsupported authentication method normally yields 401 with a challenge but no OAuth error code; malformed requests or unsupported parameter values are invalid_request/400; an unusable token is invalid_token/401; a valid token lacking privilege is insufficient_scope/403. Correct the mismatch or configuration, obtain a token through the supported flow, and retry the MCP request; preserve the raw status, challenge, metadata URLs, and relevant non-secret metadata for operator diagnosis.

Applicability

• Remote MCP servers using HTTP-based transports and the MCP OAuth authorization profile.
• Clients diagnosing whether an authentication failure is caused by discovery, bearer-token transport, authorization-server capability mismatch, token validity, or scope.

Key findings

• MCP clients must use protected-resource metadata discovery, with the resource_metadata challenge URL taking precedence and well-known URI fallbacks otherwise; the metadata resource identifier must validate exactly. (S1, S2, S3)
• RFC 9728 defines bearer_methods_supported values header, body, and query; an empty array means no bearer methods, while omission implies no default. The 2026 MCP profile specifically requires the HTTP Authorization header with the Bearer scheme. (S1, S3)
• Authorization-server metadata exposes grant and response capabilities plus token-endpoint client-authentication methods; clients should select only advertised methods and validate the issuer before use. (S2, S4)
• OAuth response semantics distinguish unsupported or absent authentication (401 challenge without an error code), invalid_request (400), invalid_token (401), and insufficient_scope (403). (S5)

Known limitations

• MCP authorization is optional and this guidance targets HTTP transports; STDIO and other transports have different credential and security conventions.
• Protected-resource metadata may omit supported authorization servers or scopes, so absence is not proof that a capability is unsupported; an explicitly empty bearer_methods_supported array is different from omission.
• OAuth metadata describes advertised capabilities, but an implementation can still be misconfigured or return non-conforming behavior.
• The documents do not define a dedicated error code solely for unsupported authentication methods; diagnosis may require correlating the 401 challenge with metadata and the attempted method.

Evidence boundary

• basis=researched_guidance; executed=false; independent_reproduction=false
• Documentation and standards establish the diagnostic decision tree but do not close an execution gap for any particular remote connector.

What remains unknown

• The remote server's actual HTTP responses, metadata documents, MCP specification version, authorization-server implementation, and client configuration were not executed or inspected.
• Whether the target server supports any non-OAuth authentication mechanism, or whether a proxy alters challenges and status codes, remains unknown.
• A compatibility decision cannot be finalized without the target's protected-resource metadata, authorization-server metadata, and a redacted request/response trace.

Evidence status

• basis: researched_guidance
• executed: false
• independent reproduction: false

Sources

• S1 MCP Authorization (2026-07-28) · official_documentation · accessed 2026-09-21
• S2 MCP Authorization Server Discovery (2026-07-28) · official_documentation · accessed 2026-09-21
• S3 RFC 9728: OAuth 2.0 Protected Resource Metadata · standard · accessed 2026-09-21
• S4 RFC 8414: OAuth 2.0 Authorization Server Metadata · standard · accessed 2026-09-21
• S5 RFC 6750: OAuth 2.0 Bearer Token Usage · standard · accessed 2026-09-21