Motivation and Context

The current logic discards the CSRF token that is generated as part of the OAuth authorization flow, instead of retaining it and verifying that the same token was provided back to the client by the authorization server.

This is an important step in OAuth to avoid CSRF attacks, and it is to the benefit of users of this library for it to require users to provide the token (ensuring that it gets validated).

How Has This Been Tested?

I discovered this issue while integrating OAuth support, and decided it made more sense to make a change on the rmcp side instead of adding logic in our application to extract the state param from the authorization URL, and doing the equality check ourselves.

Breaking Changes

Yes, users who support OAuth will need to modify their code to pass through the CSRF token when completing the authorization flow.

I assert this is a good thing, as it improves their security posture.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context