Question about OAuth 2.1 security model and MCP server aggregation

[0xAttra]

I have a question regarding the OAuth 2.1 security model in ContextForge when aggregating multiple remote MCP servers.

From what I understand, authentication currently seems to be handled at the MCP server level, meaning each remote MCP server manages its own OAuth configuration.

I have a few related questions:

1. Is authentication officially designed to remain at the MCP server level in ContextForge’s current architecture?

2. When aggregating multiple remote MCP servers that use different OAuth flows, identity providers, or scopes, how does ContextForge handle this heterogeneity?

3. Are there recommended architectural patterns for securely aggregating MCP servers with different authentication mechanisms?

4. Is there any roadmap item or plan to move authentication handling to a more centralized model (e.g., at the gateway/tool level rather than per MCP server)?

5. Is it possible (or planned) for ContextForge to propagate the remote server’s authentication requirements back to the client — essentially acting as a transparent pass-through for the authentication type and flow — so that the client can handle the appropriate OAuth interaction directly?

Thank you in advance for your clarification!

[crivetimihai]

Hi @0xAttra, great questions. Let me address each one:

1. Is authentication designed to remain at the MCP server level?

ContextForge uses a two-tier authentication model:

Layer	Flow	Purpose
Gateway-level	User → ContextForge	Authenticates users to the gateway itself (JWT, SSO, proxy auth)
MCP server-level	ContextForge → Upstream MCP	Authenticates ContextForge to upstream MCP servers on behalf of the user

These are intentionally separate concerns. The gateway authenticates and authorizes the user first (via RBAC), then uses per-gateway OAuth credentials to forward requests to upstream servers.

2. How does ContextForge handle heterogeneous OAuth across multiple MCP servers?

Each registered gateway (upstream MCP server) has its own independent OAuth configuration stored in the oauth_config field, including:

• grant_type, client_id, client_secret (encrypted at rest)
• authorization_url, token_url, scopes, resource

OAuth tokens are stored per gateway + per user (keyed by gateway_id + app_user_email). When a user invokes a tool on Gateway A, Gateway A's OAuth config and the user's tokens for that gateway are used. Gateway B can have a completely different IdP, scopes, and flow.

3. Recommended architectural patterns?

• Use the gateway's built-in per-gateway OAuth configuration — each gateway can point to a different IdP
• The Authorization Code flow with PKCE is supported for interactive authorization
• Tokens are automatically refreshed when near expiry before forwarding to upstream servers
• For non-interactive flows, client_credentials grant is also supported

4. Roadmap for centralized auth?

The current design intentionally keeps upstream auth per-gateway because different MCP servers often require different IdPs, scopes, and audiences. However, for environments where all upstream servers share a single IdP, you can configure SSO at the gateway level via SSO_GENERIC_JWKS_URI to validate tokens from a single external identity provider.

5. Can ContextForge propagate upstream auth requirements to the client (pass-through)?

Yes, this is exactly what the RFC 9728 OAuth Protected Resource metadata endpoint does. Each virtual server exposes:

GET /.well-known/oauth-protected-resource/servers/{server_id}/mcp

This tells MCP clients which external Authorization Server to authenticate against, what scopes are needed, and the resource indicator — enabling spec-compliant clients (like Claude) to handle the OAuth flow directly. The gateway acts purely as a Resource Server in this model.

See docs/architecture/oauth-design.md for the full flow documentation.

[0xAttra]

Thank you for this clear and detailed answer! It will help me a lot. 😄