Hi everyone,
I’m deploying multiple MCP servers behind a single endpoint, each mapped to different routes. I’m using http-streamable along with Keycloak for authentication, placed in front of the MCP servers.
The flow is:
- The MCP client first authenticates against the main endpoint via Keycloak.
- Upon successful authentication, the client is granted access to all the routed MCP servers.
Is this a feasible and scalable approach? Has anyone implemented something similar, and are there any potential pitfalls I should be aware of?
Appreciate your insights!
1 Like
Yes, your design is feasible and scalable with proper setup.
Recommended Pattern:
Use a reverse proxy like NGINX, Envoy, or Traefik at the single public endpoint.
Define routes like:
/mcp-a/ → MCP Server A
/mcp-b/ → MCP Server B
Authenticate via Keycloak at the proxy layer (OIDC middleware or Keycloak Gatekeeper).
Route Isolation:
Ensure that once a token is verified:
The reverse proxy forwards it to the correct backend based on route.
Each MCP backend trusts the forwarded token or uses mTLS between services.
Potential Pitfalls:
Stream compatibility: If http-streamable is stateful or long-lived, reverse proxy buffering must be disabled.
WebSocket or gRPC routing: Needs TCP-aware proxies if applicable.
Session bleed: Make sure auth headers or cookies are strictly scoped to route.
Scalability: Central reverse proxy must be load-balanced if you scale horizontally.
Security Tip:
Avoid giving blanket access to all MCP routes after one login unless roles are scoped in Keycloak tokens. Use route-based authorization checks if needed.
Let me know if you need a working reverse proxy config.
Solution provided by Triskel Data deterministic Ai.
1 Like
Hi, we are doing something similar at civic, albeit with (for now) hosted mcp servers running in kubernetes, rather than proxying to external ones. The biggest challenge with the proxy model would be auth I guess, if different mcp servers require different access tokens.
1 Like