authorization server does not advertise code_challenge_metho

Error message

authorization server does not advertise code_challenge_methods_supported

What it means

Sister check to error 170: discover() requires the auth server metadata to include the code_challenge_methods_supported field at all. When the field is absent (None after deserialization), the client refuses to proceed even though the OAuth discovery response is otherwise fine, because it cannot confirm S256 PKCE support as the MCP spec requires. Note this is stricter than plain OAuth2, where a missing field conventionally implies 'plain' only.

Source

Thrown at crates/context_server/src/oauth.rs:875

    http_client: &Arc<dyn HttpClient>,
    server_url: &Url,
    www_authenticate: &WwwAuthenticate,
) -> Result<OAuthDiscovery> {
    let resource_metadata =
        fetch_protected_resource_metadata(http_client, server_url, www_authenticate).await?;

    let auth_server_url = resource_metadata
        .authorization_servers
        .first()
        .ok_or_else(|| anyhow!("no authorization servers in resource metadata"))?;

    let auth_server_metadata = fetch_auth_server_metadata(http_client, auth_server_url).await?;

    // Verify PKCE S256 support (spec requirement).
    match &auth_server_metadata.code_challenge_methods_supported {
        Some(methods) if methods.iter().any(|m| m == "S256") => {}
        Some(_) => bail!("authorization server does not support S256 PKCE"),
        None => bail!("authorization server does not advertise code_challenge_methods_supported"),
    }

    let scopes = select_scopes(www_authenticate, &resource_metadata);

    Ok(OAuthDiscovery {
        resource_metadata,
        auth_server_metadata,
        scopes,
    })
}

/// Resolve the OAuth client registration for an authorization flow.
///
/// CIMD uses the static client metadata document directly. For DCR, a fresh
/// registration is performed each time because the loopback redirect URI
/// includes an ephemeral port that changes every flow.
pub async fn resolve_client_registration(
    http_client: &Arc<dyn HttpClient>,

View on GitHub (pinned to f4178619ac)

Solutions

Update or configure the authorization server so its metadata document advertises "code_challenge_methods_supported": ["S256"]
If using a proxy/gateway in front of the auth server, have it inject the field into the served discovery document
Upgrade the auth server to a version whose discovery document includes PKCE support advertisement

Example fix

// before (discovery document lacks the field)
{ "issuer": "https://auth.example.com", "authorization_endpoint": "..." }

// after
{ "issuer": "https://auth.example.com", "authorization_endpoint": "...",
  "code_challenge_methods_supported": ["S256"] }

Defensive patterns

Strategy: validation

Validate before calling

// client-side: treat an absent field as a hard precondition
anyhow::ensure!(
    metadata.get("code_challenge_methods_supported").is_some(),
    "auth server metadata must include code_challenge_methods_supported (MCP requires S256 PKCE)"
);

Type guard

fn advertises_pkce_methods(doc: &serde_json::Value) -> bool {
    doc.get("code_challenge_methods_supported").is_some()
}

Try / catch

match discover(&client, &server_url, &challenge).await {
    Err(err) if err.to_string().contains("does not advertise code_challenge_methods_supported") => {
        // add the field server-side; no client-side workaround exists
        report_server_requirement("add code_challenge_methods_supported to the discovery document");
        Err(err)
    }
    other => other,
}

Prevention

Never omit code_challenge_methods_supported in metadata meant for MCP clients
If you proxy the discovery document, inject the field rather than passing through an older provider response
Validate the full MCP-required field set in your metadata deployment pipeline

When it happens

Trigger: Auth server metadata JSON omits code_challenge_methods_supported entirely (the field is Option in AuthServerMetadataResponse), so discover() hits the None => bail! arm.

Common situations: Standard OIDC providers that don't include the (RFC 8414 / draft) PKCE methods field in their discovery document; minimal or hand-rolled authorization servers that implemented the required OAuth fields but skipped PKCE advertisement; older server versions predating the MCP authorization spec.

Related errors

AI-assisted analysis of zed-industries/zed@f4178619ac (2026-08-20). Data as JSON: /api/errors/f91f20a3e826c32d. Report an issue: GitHub.