Fix oauth well-known paths to retain path and query

[calclavia]

Motivation and Context

This change is the same as #687 but applied to the protected resource well known path as well.

This should be spec compliant, as per RFC 9728:

Different applications utilizing OAuth protected resources in application-specific ways MAY define and register different well- known URI path suffixes for publishing protected resource metadata used by those applications. For instance, if the Example application uses an OAuth protected resource in an Example-specific way and there are Example-specific metadata values that it needs to publish, then it might register and use the example-protected-resource URI path suffix and publish the metadata document at the URL formed by inserting /.well-known/example-protected-resource between the host and path and/or query components of the protected resource's resource identifier.

How Has This Been Tested?

Currently I've to hack around this by manually passing resourceMetadataUrl in auth

Breaking Changes

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

[calclavia]

Hey @ihrpr, I notice there's an additional issue for the previous PR: #687 - query parameters seem to be dropped. We should do as the specification says, which is simply insert .well-known after the domain, but otherwise leave the URL as-is.

Modified this PR accordingly.

[ihrpr]

Thank you! Since we released SDK package already, would be good to maintain backwards compatibility as well (#692 example). Please can you also add some tests?

[selcuktemizsoy]

@ihrpr @calclavia when shall we expect to release this? Various client implementation fails because of this.

[calclavia]

@ihrpr @calclavia when shall we expect to release this? Various client implementation fails because of this.

I haven't had a chance to write tests. If anyone could contribute, it can move this PR along faster!

[ihrpr]

okay, I went back and forth on backwards compatibility for this. As the current implementation is not spec compliant I'm willing to accept it and just release as minor release making as behaviour changes and it should be spec compliant.

Tried to add tests to this branch, but don't have permissions. Added them here: #756

[calclavia]

@ihrpr Ok great - should we close this PR then since it's a dupe?

[ihrpr]

Closing as duplicate, let's continue in #756