diff options
| author | Dhravya <[email protected]> | 2026-01-12 23:38:30 +0000 |
|---|---|---|
| committer | Dhravya <[email protected]> | 2026-01-12 23:38:30 +0000 |
| commit | e94134cd2691051c857f81a8b325d0402cc38853 (patch) | |
| tree | 5c2f3dd07206ef4dc1a6c9fe9aabb768078fc5d8 /apps/docs/docs.json | |
| parent | Document MCP context prompt feature (#661) (diff) | |
| download | supermemory-e94134cd2691051c857f81a8b325d0402cc38853.tar.xz supermemory-e94134cd2691051c857f81a8b325d0402cc38853.zip | |
fix: oauth discovery not working with some clients (#666)01-12-fix_oauth_discovery_not_working_with_some_clients
### 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.
Diffstat (limited to 'apps/docs/docs.json')
0 files changed, 0 insertions, 0 deletions