Support PKCE with S256

This check verifies that your authorization server advertises PKCE with the S256 method in code_challenge_methods_supported.

Check id pkce. Results:

pass fail skipped

Why it matters

PKCE protects the authorization code. When the user signs in, the agent sends a hash of a random secret, the code challenge. When it exchanges the code, it sends the secret itself, the code verifier. Someone who intercepts the code cannot use it without the verifier. With the S256 method the challenge is a SHA-256 hash; with plain it is the secret itself, which protects nothing if the authorization request is seen.

The MCP authorization specification makes PKCE mandatory for clients, requires S256, and tells clients to refuse to proceed when code_challenge_methods_supported is absent from the metadata (Authorization code protection). Agents check the metadata before they start, so an authorization server that supports PKCE but does not say so in its metadata is treated as one that does not support it.

• ChatGPT says code_challenge_methods_supported must include S256, and that servers whose metadata omits the field or does not advertise S256 are unsupported (OpenAI: Authentication).
• Claude sends a code challenge with code_challenge_method=S256 on every authorization request, and requires the authorization server to support it and advertise "code_challenge_methods_supported": ["S256"] (Claude: Authentication for connectors).
• Other agents follow the MCP specification. MCP Tower has not verified them.

What MCP Tower checks

1. MCP Tower reads the authorization server metadata that the authorization server metadata check found and validated.
2. It looks for the string S256 in the code_challenge_methods_supported array. The comparison is exact, so s256 does not count.
3. If S256 is listed, the check passes. If the field is missing, empty, or lists only other methods such as plain, the check fails.
4. If discovery stopped earlier, the check is skipped with the reason of the step that stopped it.

A failed pkce check means MCP Tower does not offer Sign in to scan, because every agent would refuse to continue. When you do sign in, MCP Tower always uses S256, as agents do.

Results

Status	Message	Meaning	Fix
pass	PKCE with S256 is supported.	The metadata lists S256.
fail	code_challenge_methods_supported does not include S256. The MCP authorization spec requires it.	The field is missing from the metadata.	Advertise S256
fail	code_challenge_methods_supported does not include S256. The MCP authorization spec requires it.	The field lists only plain or another method.	Enable S256
skipped	Needs the protected resource metadata.	Discovery stopped at protected resource metadata.	Fix that check first
skipped	Needs an authorization server.	Discovery stopped at authorization servers.	Fix that check first
skipped	Needs the authorization server metadata.	Discovery stopped at server metadata.	Fix that check first
skipped	Needs valid authorization server metadata.	The metadata’s issuer did not match; see server metadata.	Fix that check first

The next step for the failure is: “Enable PKCE with S256 on your authorization server.”

How to fix

The metadata does not advertise PKCE

An authorization server can support PKCE and still leave the field out of its metadata. OpenID Connect Discovery does not define the field, but MCP requires authorization servers that publish OpenID Connect discovery to include it.

1. Check whether your authorization server accepts a code_challenge with code_challenge_method=S256 on its authorization endpoint. If it does, only the metadata is wrong.
2. Find the setting that controls the published metadata, or the code that builds it, and add code_challenge_methods_supported with S256.
3. Fetch the metadata again and confirm the field is there.

Only plain is enabled

1. Enable PKCE with the S256 method for the authorization code grant in your authorization server.
2. Allow it for public clients too. Claude’s Client ID Metadata Document client is a public client with no secret, so PKCE is its only protection for the code.
3. You can keep plain listed for old clients, but list S256 as well. The MCP specification requires clients to use S256 when they can.

Metadata that passes:

https://auth.example.com/.well-known/oauth-authorization-server

{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "response_types_supported": ["code"],
  "code_challenge_methods_supported": ["S256"]
}

Caution

Advertising S256 is not enough on its own. The token endpoint must also verify the code_verifier against the challenge it stored with the code, and reject the exchange with invalid_grant when they do not match. See token exchange.

Check it yourself

Print the methods your authorization server advertises:

curl -s https://auth.example.com/.well-known/oauth-authorization-server \
  | jq '.code_challenge_methods_supported'

The problem is fixed when the list includes S256:

["S256"]

null means the field is missing, and ["plain"] means S256 is not enabled. If your issuer has a path, or you publish OpenID Connect discovery instead, use the metadata URL that the server metadata check reported as found. Then select Scan again on the server’s page.

References

• RFC 7636 §4.2: the code challenge and the S256 and plain methods
• RFC 8414 §2: the code_challenge_methods_supported metadata field
• MCP authorization 2026-07-28: Authorization code protection
• OpenAI: Authentication, “Publish OAuth metadata from your authorization server”
• Claude: Authentication for connectors, “PKCE and requested scopes”