Description
Is your feature request related to a problem? Please describe.
When embedding an MCP client into an application that already has its own authentication mechanism - such as a mobile app, a server with an identity layer, or in my case, a VS Code extension - there’s no clean way to reuse that existing auth flow.
Currently, the SDK requires a full end-to-end OAuth flow even when a valid token is already managed elsewhere. If I want to inject my own logic (e.g., refresh a token silently or use a system credential store), the only workaround is to subclass SSEClientTransport and/or StreamableHTTPClientTransport and override methods like send. Unfortunately, the relevant methods are mostly private or tightly coupled, which makes this approach fragile and hard to maintain over time.
Describe the solution you'd like
I’ve proposed an optional method, OAuthClientProvider.delegateAuthorization, that lets clients provide their own pre-auth logic.
If implemented, this hook is called before the SDK starts the standard OAuth flow. If it returns "AUTHORIZED", the SDK skips its own auth logic. If it returns undefined, everything proceeds as normal.
This enables use cases like:
- Refreshing tokens from a shared identity system
- Using ambient credentials from a native environment
- Rehydrating persisted sessions from the host app
Describe alternatives you've considered
As mentioned, the only current workaround is to subclass the transport classes and override private methods—reimplementing large chunks of code like send or _authThenStart. This is brittle and makes it harder to keep up with SDK changes.
Additional context
The proposed solution is passive and backward-compatible. If you don’t implement delegateAuthorization, nothing changes. But if you do, you gain full control over how your client handles the first authorization event (e.g., after a 401).
Would love your thoughts on the proposal in PR #485!