Solving Multi-Instance OAuth for MCP on Cloud Foundry

[himavaishnavijidugu]

In my previous blog, I mentioned a challenge we faced while running our MCP server with multiple instances on Cloud Foundry. The issue was around session state and how data stored in one instance is not accessible to another.

Let me share what we tried, where we got stuck, and how we approached the solution.

Here’s how we investigated it and the approach we explored.

1. Understanding the Issue

Our MCP server uses XSUAA for OAuth authentication with Joule Work Desktop (JWD).

The flow looked something like this:

1. JWD starts the OAuth flow.

2. After authorization, XSUAA redirects the request to our callback endpoint.

3. Our server exchanges the authorization code for a JWT.

4. JWD calls the token endpoint to obtain the token.

The problem appeared when we deployed multiple instances. The callback could reach Instance 1, while the token request reached Instance 2.

Since the required OAuth data was stored in Instance 1's local memory, Instance 2 couldn't retrieve it.

2. What We Tried

Sticky sessions

We tried keeping requests on the same instance. However, we didn't want the authentication flow to rely entirely on request routing.

FastMCP stateless mode

We enabled stateless_http=True. This helped with FastMCP session tracking, but our custom OAuth state was still stored locally, so the problem remained.

Temporary code exchange

We also explored generating an mcpCode after receiving the JWT. JWD would send this code to the token endpoint, and the server would use it to retrieve the JWT.

The challenge was that we still needed to store the mapping between mcpCode and the JWT. Without a shared store, another instance wouldn't have access to that mapping.

The Approach We Explored:

Instead of storing the JWT and passing a reference to retrieve it later, we explored carrying the token through the redirect URL.

After exchanging the authorization code for a JWT, our server encoded the token and included it in the redirect. JWD then passed the value to the token endpoint, which could process it without looking up data stored by another instance.

This removed the dependency on local in-memory state between the two requests. One instance could handle the callback, while another could handle the token request.

The key takeaway: When building MCP servers for Cloud Foundry, we need to consider how authentication state behaves when requests move between instances, not just whether the MCP server itself is stateless.

For those who prefer visual explanations, like me, I've also included an architecture diagram to make the OAuth flow, the multi-instance challenge, and our approach easier to understand.