Best way to handle OAuth with the C# MCP client? Slightly different flow

[RohanChintakindi]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

I’m trying to integrate the C# MCP client (with Authorization) into my program, but I’m hitting issues with how token state is managed.

My desired flow looks like this:

MCP client calls the MCP server → gets a 401 → queries PRM/AS metadata.
Backend crafts the auth URL with PKCE and passes it to the frontend.
User logs in in the browser, frontend captures the code, and posts it (with PKCE verifier) back to the backend.
Backend exchanges the code at the token endpoint, stores the access_token/refresh_token, and forwards the access_token to the frontend (Redux/browser storage).
Later I want to refresh tokens in the backend, but the SDK abstracts away the token endpoint and isn’t stateful.

Complication: my app instantiates a new MCP client on every request through Semantic Kernel, so I can’t rely on the SDK holding onto token state. Right now it looks like I’d need my own token broker, but that defeats some of the built-in OAuth support in the SDK.

Questions:
Should I roll my own OAuth/token broker that handles discovery, exchange, and refresh, then inject tokens into the MCP client?
Or should I fork the SDK to expose the token endpoint/state?
Is there a supported pattern to reuse tokens and handle refresh with Semantic Kernel in this setup?
Is it possible that a future update in the SDK can include maybe public interfaces that are accessible for us to implement ourself assuming most of the DTOs and classes are sealed for security concerns? Will help to adapt the client to different scenarios.

What’s the best option here?

Would appreciate your help mate @localden , thank you!

[MysteriousVoid]

In most production setups, you do want a dedicated OAuth/token broker sitting outside of the MCP SDK lifecycle.
Since your Semantic Kernel flow creates a new MCP client instance for each request, relying on the SDK’s internal state isn’t practical. The broker pattern solves this by:

• Handling discovery (via the MCP server metadata).
• Managing dynamic client registration when required.
• Owning token exchange + refresh, independent of client instantiation.
• Supplying short-lived access tokens back into the MCP client whenever it’s spun up.

That way, the SDK is still useful for wiring up MCP transport, but it’s not responsible for persistence or refresh. Forking the SDK to expose its internal token state is generally brittle and harder to maintain as updates land.

A common pattern is:

• Frontend does the PKCE/browser login.
• Backend broker handles the exchange, stores refresh tokens, and issues short-lived access tokens.
• Each new MCP client instance just gets injected with a fresh access token from the broker.

That aligns with how OAuth is usually integrated in stateless environments.

The fastest way forward is to lean on a third-party auth solution that already handles the broker responsibilities (discovery, exchange, refresh) so you don’t have to re-implement them yourself - for example, see Scalekit’s MCP Auth overview.