Support Conditional OAuth Validation for Internal vs External Clients

[vengateshganesangv]

Description:
Currently, the Apollo MCP Server enforces OAuth 2.1 authentication for all incoming client connections according to the MCP Authorization Specification. This requires every client to provide a valid OAuth token or go through the OAuth flow.

We have two configurations currently:

1. Skip OAuth completely (for internal/local usage):

schema:
  source: local
  path: /data/schema/schema.graphql
operations:
  source: local
  paths:
    - /data/operations/query/applicationById.graphql
transport:
  type: streamable_http
  address: 0.0.0.0
  port: 5000
forward_headers:
  - Authorization
endpoint: http://api-endpoint:8080/graphql

2. Enforce OAuth (for external clients):

transport:
  type: streamable_http
  auth:
    servers:
      - https://auth.example.com
    audiences:
      - https://api.example.com
      - https://mcp.example.com

Use Case / Problem:

We have real-time applications with internal MCP clients (e.g., chatbots) that are accessed after login to the main application. These internal clients do not need to go through the OAuth flow again.

However, external clients (e.g., VS Code, Claude) connecting to the same MCP server should follow the standard OAuth flow.

Proposed Feature:

Introduce an option called allow_external_auth_header inside auth field in yaml config to conditionally enforce OAuth validation:

If allow_external_auth_header is true→ skip OAuth validation.

If allow_external_auth_header header is false→ initiate standard OAuth flow.

transport:
  type: streamable_http
  auth:
    servers:
      - https://auth.example.com
    allow_external_auth_header: true //Default to false
    audiences:
      - https://api.example.com
      - https://mcp.example.com
    forward_headers:
       - Authorization

This would allow MCP servers to support both internal trusted clients and external clients securely. As if we have token exchange also in place before hit actual API so any way it will be secure for internal clients too.

References / Notes:

FastMCP already supports this feature for conditional OAuth enforcement in the middleware.

This would improve developer experience for internal applications while maintaining security for external access.

Currently, there is no way to conditionally enforce OAuth validation based on the presence of the Authorization header. FastMCP supports this feature, allowing internal clients to bypass OAuth if they already provide a valid authorization header.

[vengateshganesangv]

@DaleSeo Could you please help in this

[vengateshganesangv]

@gocamille @DaleSeo . As this is one of the requirements that is currently blocking our upcoming release, I wanted to confirm if the above approach looks good to move forward with. If the plan is acceptable and if it take time for to solve, I will begin contributing toward it.

[gocamille]

Hey @vengateshganesangv, thanks for the detailed issue and the PR! We appreciate you taking the time to contribute.

We've been thinking through this use case and wanted to share some thoughts before we decide on an approach.

The scenario you described where internal clients (like chatbots) that are already authenticated by a parent application is understandable, but bypassing token validation is considered insecure. The recommended pattern is token exchange or validation at the gateway, rather than blind passthrough.

The current PR would have the following effects:

• No signature verification -- we can't confirm the token wasn't forged
• No expiry/revocation checks -- expired or revoked tokens would still work
• No scopes extracted -- the ValidToken has empty scopes which could break scope enforcement
• No audit trail -- we lose user identity information from token claims

Instead, we'd suggest validating against additional trusted issuers. This approach:

• Still validates tokens (signature, expiry, audience)
• Extracts scopes from claims (scope enforcement works)
• Maintains an audit trail (user identity from claims)
• Keeps external clients on the standard OAuth flow

This aligns with the MCP Authorization spec, which states: "MCP servers MUST validate that tokens presented to them were specifically issued for their use."

Would this approach work for your use case? If your internal chatbot's parent application issues JWTs with a known issuer and JWKS endpoint, this would let you accept those tokens directly while retaining full validation guarantees.

Happy to discuss further or clarify anything!