Fix client_secret not sent during OAuth token exchange#137
Open
plehoux wants to merge 1 commit intopatvice:mainfrom
Open
Fix client_secret not sent during OAuth token exchange#137plehoux wants to merge 1 commit intopatvice:mainfrom
plehoux wants to merge 1 commit intopatvice:mainfrom
Conversation
When a server returns a client_secret during dynamic registration but omits token_endpoint_auth_method, the gem was defaulting to "none" and silently dropping the secret from all token requests. This breaks any MCP server that expects client_secret in the POST body (e.g. Canny). Per RFC 7591 §2, the default is "client_secret_basic", but in practice most MCP servers only support "client_secret_post". The fix: - client_registrar: infer auth method from the registration response — if client_secret is present but token_endpoint_auth_method is not, default to "client_secret_post" instead of "none" - token_manager: replace add_client_secret_if_needed with a proper apply_client_auth! that supports both client_secret_post (body) and client_secret_basic (HTTP Basic header per RFC 6749 §2.3.1) - token_manager: route all token requests (auth code, client creds, refresh) through the same auth method so the secret is always sent when it should be
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a server returns a
client_secretduring dynamic registration but omitstoken_endpoint_auth_method, the gem was defaulting to"none"and silently dropping the secret from all token requests. This breaks any MCP server that expectsclient_secretin thePOSTbody (e.g. Canny).Per RFC 7591 §2, the default is
"client_secret_basic", but in practice most MCP servers only support"client_secret_post". The fix:client_registrar: infer auth method from the registration response — if client_secret is present buttoken_endpoint_auth_methodis not, default to "client_secret_post" instead of "none"token_manager: replaceadd_client_secret_if_neededwith a properapply_client_auth!that supports bothclient_secret_post(body) andclient_secret_basic(HTTP Basic header per RFC 6749 §2.3.1)token_manager: route all token requests (auth code, client creds, refresh) through the same auth method so the secret is always sent when it should beDiscovered and tested against Canny's MCP server (https://canny.io/api/mcp), which returns
client_secretduring registration but omitstoken_endpoint_auth_method. Token exchange was failing with 400 "invalid input" because the secret was never sent.To test Canny MCP server you need a paid account, but I can ask the co-founder to create you a test account.