Per-session JWT

[raffaeler]

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

Let's say I have:

• an ASP.NET Web API configured to authenticate a user via OpenID Connect
• an ASP.NET host with an MCP server
  When the WebAPI starts, I also connect to the MCP Server so that the tool calls are faster.

Now, when the user make a requests to the WebAPI, I want to use the "access token" (JWT) to call the MCP Server so that the tools calls authorize the user.

I have some ideas, but I wonder whether there is some "best practice" to follow, without reinventing the wheel.

Thanks

[ryux1]

Treat the HTTP connection pool and the logical MCP client/session as different lifetimes. Reuse sockets, but do not keep one startup-wide McpClient and replace its bearer token for whichever user happens to make the next request.

There are two reasons:

1. The token accepted by your Web API is normally audience-bound to that API. Obtain a downstream token for the MCP server audience/scopes using the identity provider's on-behalf-of or token-exchange flow; do not blindly forward the incoming JWT.
2. A stateful Streamable HTTP/SSE client can own a session and a long-lived GET stream. Changing identity inside that session can mix server-side session state, notifications, and authorization between users. HttpClientTransportOptions.AdditionalHeaders is also transport configuration applied to all requests, not a per-call user-token slot.

A safe shape is:

• authenticate the Web API request normally;
• exchange/acquire an MCP-audience access token for that user;
• create or retrieve an McpClient scoped to that stable user/tenant and MCP server (or create one per request when using the current stateless protocol);
• construct HttpClientTransport with an HttpClient from IHttpClientFactory, using a DelegatingHandler that attaches the downstream bearer token;
• dispose/evict the logical MCP client when the user session or token context ends.

Key caches by stable subject + tenant + MCP audience, never by a caller-supplied token string, and do not share one stateful MCP session across subjects. IHttpClientFactory still gives connection pooling, so per-user logical clients do not require a new TCP connection for every tool call. If the token expires, acquire a fresh downstream token; for a stateful session, keep the authenticated subject invariant.

On the server, use ordinary ASP.NET Core JWT bearer authentication, MapMcp().RequireAuthorization(), and AddAuthorizationFilters() when tools/resources have authorization metadata. Tool handlers can receive ClaimsPrincipal directly. Current Streamable HTTP handling uses fresh HttpContext authentication on each request; legacy SSE has a stale-context caveat because its HttpContext belongs to the long-lived stream.

Current SDK references:

• transport construction and AdditionalHeaders: https://github.com/modelcontextprotocol/csharp-sdk/blob/main/docs/concepts/transports/transports.md#streamable-http-client
• identity and transport behavior: https://github.com/modelcontextprotocol/csharp-sdk/blob/main/docs/concepts/identity/identity.md#transport-considerations
• complete protected JWT server sample: https://github.com/modelcontextprotocol/csharp-sdk/tree/main/samples/ProtectedMcpServer

So the short answer is: reuse the underlying HttpClient infrastructure, but scope the McpClient/session and downstream credential to one authenticated principal.