| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
### TL;DR
TESTING REMAINING. This is my hypothesis. @MaheshtheDev please carry on from here or we can test in prod.
Added a proxy endpoint for OAuth authorization server metadata to support non-compliant MCP clients.
### What changed?
Added a new endpoint `/.well-known/oauth-authorization-server` to the MCP server that proxies requests to the main API. This endpoint fetches the authorization server metadata from the API and returns it to clients.
### How to test?
1. Make a GET request to `/.well-known/oauth-authorization-server` on the MCP server
2. Verify that it returns the same metadata as the main API's `/.well-known/oauth-authorization-server` endpoint
3. Test with a client that expects to find the authorization server metadata on the MCP domain
### Why make this change?
Some MCP clients don't correctly follow the OAuth specification. Instead of using the `authorization_servers` array provided in the protected resource metadata, they look for the authorization server metadata directly on the MCP server domain. This proxy endpoint ensures compatibility with these non-compliant clients without requiring them to be updated.
|