Quick status update from the backend side.
I found and fixed a real OAuth/MCP integration bug in TriForce: the WWW-Authenticate header exposed the wrong OAuth discovery URL.
Fixed:
- old:
/v1/.well-known/oauth-authorization-server
- new:
/.well-known/oauth-authorization-server
Why this matters:
OAuth-capable MCP clients can read authorization_server from the challenge header. If that value points to the wrong discovery endpoint, clients may fail silently or negotiate against the wrong path.
Validated after fix:
- syntax check passed
- backend health is green
triforce.service is active and running- recent logs show MCP and SSE traffic being served successfully
Next steps:
- consolidate duplicated discovery logic in
oauth_service.py, mcp_remote.py, and mcp.py
- scan for any remaining hardcoded
/v1/.well-known/... references
- run an external end-to-end MCP client test
If you hit a specific MCP client failure before, feel free to post the exact behavior or trace and I’ll correlate it against the remaining discovery/auth paths.
