IDataProtectionProvider default implementation prevents use of stateless with a load balancer

[johnthcall]

Describe the bug
Because the StatelessSessionId is protected via IDataProtectionProvider when a second instance of the server receives the subsequent request it tries to unprotect the sessionId header which throws System.Security.Cryptography.CryptographicException: The key {59baa26c-5757-494e-bc99-c7a2d3331425} was not found in the key ring. For more information go to https://aka.ms/aspnet/dataprotectionwarning
When running from a client via McpClientFactory.CreateAsync this does not reproduce as the connection is reused and the same instance is hit. When integrating with VS Codes Copilot the tools/list call appears to be establishing another request and as a result failing.

To Reproduce
Steps to reproduce the behavior:

1. After initializing to the server and getting a sessionId back.
2. either reboot the server or have the subsequent request use a new connection.
3. Make a subsequent request passing the sessionId header.

Expected behavior
Stateless either does not depend on this stateful data protection or there is documentation for how to implement the IDataProtectionProvider so that cross instance requests can be processed.

Logs
StackTrace:
Microsoft.AspNetCore.DataProtection.KeyManagement.KeyRingBasedDataProtector.UnprotectCore(Byte[] protectedData, Boolean allowOperationsOnRevokedKeys, UnprotectStatus& status)
at Microsoft.AspNetCore.DataProtection.KeyManagement.KeyRingBasedDataProtector.Unprotect(Byte[] protectedData)
at Microsoft.AspNetCore.DataProtection.DataProtectionCommonExtensions.Unprotect(IDataProtector protector, String protectedData)
at ModelContextProtocol.AspNetCore.StreamableHttpHandler.GetSessionAsync(HttpContext context, String sessionId)
at ModelContextProtocol.AspNetCore.StreamableHttpHandler.GetOrCreateSessionAsync(HttpContext context)
at ModelContextProtocol.AspNetCore.StreamableHttpHandler.HandlePostRequestAsync(HttpContext context)

Additional context
Running 0.2.0-preview.3 on windows so under the hood CngGcmAuthenticatedEncryptorConfiguration is used.

[halter73]

Expected behavior
Stateless either does not depend on this stateful data protection or there is documentation for how to implement the IDataProtectionProvider so that cross instance requests can be processed.

I wouldn't call data protection "stateful". It's merely a mechanism for sharing encryption keys. It's certainly less stateful than the default mode which requires sticky sessions, so requests belonging to the same MCP session go to the same server process with the same data in-memory.

ASP.NET Core authentication cookies also requires data protection to work in web farm scenarios, but I don't think that makes it stateful. I found an issue on another repo where someone else argued that data protection is not really stateless, so you're not alone in thinking that. But as you can see from the replies, I'm not alone in my opinion that this is stateless either.

If you have a better name for HttpServerTransportOptions.Stateless, I'm all ears. We're still in preview, but I think most ASP.NET Core developers would consider a server that relies on data protection still stateless.

either reboot the server or have the subsequent request use a new connection.

Are you running in a container or doing something else that would reset the home directory? By default, data protection keys are stored there, so they should survive a simple reboot. However, unless you're running on Azure App Service, you must manually configure ASP.NET Core Data Protection to have it work behind a load balancer.

If you're not hosting in Azure, PersistKeysToFileSystem or PersistKeysToDbContext might be of interest. Since data protection only shares keys and not any application state, it should require very little storage.

https://learn.microsoft.com/aspnet/core/security/data-protection/configuration/overview
https://learn.microsoft.com/aspnet/core/security/data-protection/configuration/default-settings#key-management
https://learn.microsoft.com/aspnet/core/host-and-deploy/web-farm

Most of those links can be found from the https://aka.ms/aspnet/dataprotectionwarning link in the exception message. Is there some reason you cannot configure data protection manually?

We could consider a new sessionless mode that does not need state or data protection. But so long as a concept of a session exist, I want to continue ensuring that the user stays the same for a given session. We have a test for this.

Other than the user id, the only other thing we currently encrypt are the client capabilities. that probably doesn't need to be encrypted, since we're already completely trusting the client to give us accurate info for that anyway. There's currently an MCP protocol proposal at modelcontextprotocol/modelcontextprotocol#493 that would allow clients to resend their capabilities with each request, and then we wouldn't even have to round-trip this info in the mcp-session-id header, so maybe we should wait to see what comes of that.