A client fetches OAuth 2.0 authorization server metadata before starting authorization and finds that code_challenge_methods_supported is absent. What must the client do?
Select an answer to reveal the explanation.
Short Explanation
PKCE is the tamper seal on the authorization code. If the authorization server can't show you it supports one, you don't open the package. Don't fall for "use plain instead"; the spec says stop.
Full Explanation
MCP clients must implement PKCE according to OAuth 2.1 and must verify PKCE support before proceeding with authorization. PKCE prevents authorization code interception and injection by requiring a secret verifier and challenge pair, so only the original requester can redeem the code. Clients must use the S256 challenge method when technically capable. Because OAuth 2.1 and PKCE define no discovery of their own, clients rely on authorization server metadata: with OAuth 2.0 Authorization Server Metadata, if code_challenge_methods_supported is absent the authorization server does not support PKCE and clients must refuse to proceed. Proceeding with plain fails because absence of the field means no PKCE support at all, not a default method, and S256 is required where possible. Proceeding without PKCE because of the resource parameter fails by concept: the resource parameter binds a token's audience to a server; it does nothing to stop a stolen authorization code being redeemed. Falling back to Dynamic Client Registration fails because registration only obtains a client ID; it cannot add PKCE to an authorization server that lacks it, and that mechanism is deprecated. Exam caveat: the refusal is a client-side MUST, so a compliant client stops even if the server would otherwise work. Operational check: remove the field from a test server's metadata and confirm the client halts.