-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Description
Auth Retry Handling for Remote MCP Proxies
Current Behavior
We use _hasCompletedAuthFlow to prevent infinite recursion during MCP Server authentication, which works well for standard use cases.
The Challenge
When building custom proxies like mcp-remote or mcp-connector, we need more flexible authentication retry logic.
Remote MCP Servers often use scope-based authentication, where each tool requires specific permissions. This creates a scenario where:
- A user adds a new tool to their MCP Server
- When they try to execute it, the request returns a 401 Unauthorized error
- This happens because the local access token stored in the proxy doesn't include the scope required for the new tool
Required Solution: Two-Tier Retry Strategy
Case 1: Token Refresh
Attempt to obtain a new access token using the existing refresh token (with updated scopes).
Case 2: Full Re-authentication
If token refresh fails, restart the entire authentication flow from scratch.
The Problem
Once _hasCompletedAuthFlow is set to true, any subsequent authentication attempts throw an error. This prevents Case 2 from being implemented, leaving proxies unable to handle full re-authentication scenarios.
Proposed Solution
Expose _hasCompletedAuthFlow through one of the following approaches:
- Add a public getter method to check the authentication state
- Make the variable public to allow direct access
This would enable custom proxy implementations to:
- Check the current authentication state
- Reset the flag when full re-authentication is needed
- Implement proper retry handling without functionality breakage