Token passthrough violates MCP specification - architectural considerations for authentication

Summary

The current implementation of rmcp-openapi-server forwards Authorization headers from MCP clients directly to backend OpenAPI services. This violates the MCP specification which states: "MCP servers MUST NOT pass through the token it received from the MCP client."

Current Architecture

MCP Client → [Bearer token A] → rmcp-actix-web → [Bearer token A] → rmcp-openapi-server → [Bearer token A] → OpenAPI Backend

This creates a potential "confused deputy" vulnerability where tokens intended for the MCP server are being used at backend APIs.

The Challenge: Alternative Approaches

If rmcp-openapi-server were to comply with the MCP specification and act as its own OAuth client, several problematic scenarios arise:

Option 1: Single Service Account

All MCP Users → MCP Server → [uses single service account] → Backend API

Problems:

  • Loss of user identity: Backend can't distinguish between users
  • Audit trail broken: All actions appear to come from one account
  • Authorization bypass: Users might access resources they shouldn't have access to
  • Rate limiting issues: All traffic counts against one account

Option 2: User Account Mapping

MCP User A → MCP Server → [maps to Backend User A credentials] → Backend API

Problems:

  • Credential storage: MCP server needs to store backend credentials for each user
  • Security risk: MCP server becomes a honey pot of user credentials
  • Initial setup: How does the MCP server obtain these credentials?
  • Token refresh: MCP server needs to handle OAuth flows for each user

Option 3: OAuth Delegation/Impersonation

MCP User → MCP Server → [requests delegated token for user] → Backend API

Problems:

  • Backend must support delegation: Requires OAuth 2.0 Token Exchange (RFC 8693)
  • Not widely supported: Most APIs don't implement delegation
  • Complex setup: Requires pre-established trust relationship between MCP server and backend

Option 4: Just-in-Time OAuth Flow

MCP User → MCP Server → [initiates OAuth flow] → User authorizes → Backend API

Problems:

  • User experience: User must authorize through MCP server's OAuth flow
  • Session management: MCP server must maintain OAuth sessions per user
  • Token storage: Where does MCP server store refresh tokens?
  • Breaks MCP flow: MCP protocol doesn't support interactive OAuth flows

Why Token Passthrough Makes Practical Sense

For rmcp-openapi-server's specific use case (exposing existing OpenAPI endpoints as MCP tools), token passthrough actually provides:

  1. Preserves user identity: Backend sees the actual user's token and can apply user-specific authorization
  2. Maintains authorization boundaries: Backend's existing auth rules apply correctly
  3. Simple and secure: No credential storage or mapping needed
  4. Works with any OAuth backend: No special delegation support required
  5. Audit trail preserved: Backend can track which user performed which action

The Specification vs Reality Gap

The MCP specification's requirement appears to assume one of:

  1. Backend APIs support sophisticated delegation mechanisms (rarely true)
  2. User-specific authorization isn't needed (problematic for multi-tenant systems)
  3. MCP servers should implement full OAuth authorization servers (complex and out of scope)

None of these assumptions hold for typical OpenAPI/REST API proxying scenarios.

Proposed Solution

1. Configuration-Based Approach

Allow users to choose the authentication mode based on their security requirements:

authentication:
  mode: passthrough  # or "service_account" or "oauth_client"
  
  # For passthrough mode (current behavior)
  passthrough:
    validate_audience: false  # Optionally validate token audience
    
  # For service account mode (MCP-compliant but loses user context)
  service_account:
    client_id: "..."
    client_secret: "..."
    token_endpoint: "..."
    
  # For OAuth client mode (complex but fully compliant)
  oauth_client:
    client_id: "..."
    client_secret: "..."
    authorization_endpoint: "..."
    token_endpoint: "..."
    delegation_supported: false

2. Clear Documentation

  • Document that passthrough mode doesn't comply with MCP specification
  • Explain the security implications and when each mode is appropriate
  • Provide guidance on token scoping for passthrough mode

3. Security Warnings

When running in passthrough mode, emit a warning:

WARNING: Running in token passthrough mode. This mode forwards MCP client tokens directly to backend APIs, 
which does not comply with MCP security specifications. Ensure clients obtain tokens properly scoped for 
the backend API, not just the MCP server.

Questions for Discussion

  1. Is token passthrough an acceptable pattern for MCP proxy servers that don't process requests themselves?
  2. Should the MCP specification distinguish between "MCP servers" (that process requests) and "MCP proxies" (that forward to existing APIs)?
  3. How should MCP proxy servers handle user-specific authorization without token passthrough?
  4. Would a formal "MCP Proxy" specification extension be valuable?

Related Issues

  • rmcp-actix-web #26 (closed): Authorization header not forwarded for existing sessions (this enables the passthrough pattern)
  • MCP Specification: Authorization section that defines the token handling requirements

Impact

This architectural decision affects:

  • Security posture of deployments using rmcp-openapi-server
  • Compliance with MCP specification
  • User authorization and audit trails
  • Complexity of configuration and deployment