MCP OAuth fails with Snowflake — S256 PKCE not supported when code_challenge_methods_supported is absent from metadata

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Background Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Cursor cannot connect to Snowflake’s managed MCP server via OAuth. The error indicates S256 is not
supported.

The root cause is that Snowflake’s OAuth authorization server metadata
(/.well-known/oauth-authorization-server/oauth) does not include the code_challenge_methods_supported
field in its response. Cursor appears to treat the absence of this field as “PKCE not supported” and
rejects the connection.

Snowflake does support S256 PKCE — other MCP clients (e.g. Claude Code) connect successfully using it.
The field is simply not advertised.

Steps to Reproduce

  1. Add a Snowflake managed MCP server to Cursor:
    https://.snowflakecomputing.com/api/v2/databases//schemas//mcp-servers/<SERVER_NA
    ME>
  2. Cursor discovers the OAuth authorization server via the protected resource metadata at
    /.well-known/oauth-protected-resource/api/v2/databases/… (this works fine)
  3. Cursor fetches the authorization server metadata at /.well-known/oauth-authorization-server/oauth
  4. The metadata response is missing code_challenge_methods_supported:
    {
    “authorization_endpoint”: “https://.snowflakecomputing.com/oauth/authorize”,
    “token_endpoint”: “https://.snowflakecomputing.com/oauth/token-request”,
    “issuer”: “https://.snowflakecomputing.com/oauth”,
    “response_types_supported”: [“code”],
    “grant_types_supported”: [“authorization_code”, “refresh_token”,
    “urn:ietf:params:oauth:grant-type:token-exchange”],
    “token_endpoint_auth_methods_supported”: [“client_secret_basic”, “client_secret_post”,
    “private_key_jwt”]
    }
  5. Cursor fails with an error about S256 not being supported

Expected Behavior

Cursor should default to S256 when code_challenge_methods_supported is absent from the metadata,
rather than failing. It should only reject if the field is present and does not include S256.

The MCP TypeScript SDK had the exact same bug
(Azure OIDC discovery metadata missing code_challenge_methods_supported breaks S256 PKCE validation · Issue #832 · modelcontextprotocol/typescript-sdk · GitHub) and fixed it in
Default to S256 code challenge if not specified in authorization server metadata by LucaButBoring · Pull Request #992 · modelcontextprotocol/typescript-sdk · GitHub (merged October 2025) by changing the
validation to only reject when the field is explicitly present without S256. Azure/Entra ID and AWS
Cognito have the same missing field issue, so this fix would improve compatibility with multiple OAuth
providers.

Screenshots / Screen Recordings

SCR-20260402-otiz.png
SCR-20260402-otiz.png717×469 29.1 KB

Operating System

Linux

Version Information

Agent type: Cursor Cloud autonomous coding agent
OS: Linux
Kernel: 6.1.147
Shell: bash

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Thank you for the detailed bug report with the exact reproduction steps and references to the upstream MCP SDK fix — this is extremely helpful.

You’re correct that this is a PKCE validation bug. I’ve escalated this to our engineering team.

If you need to use Snowflake’s MCP server urgently, it may work in the local IDE (Cursor desktop) where the fix is already deployed — though that depends on whether you’re using a streamable HTTP connection there as well. I’ll update this thread when the fix is deployed.