Higress: Added API authentication capabilities from MCP Server to backend services

As a powerful AI-native API gateway, Higress is committed to paving the shortest, safest, and most cost-effective connection path between AI and the real world. One of its core capabilities is to support the seamless conversion of existing OpenAPI specifications to MCP Servers, allowing AI to quickly and conveniently call various stock API services. With Higress, enterprises and developers can instantly convert their valuable API assets into remote MCP Servers available to AI, greatly accelerating the implementation and innovation of AI applications.

When integrating AI with external services through Higress hosted MCP Server, there are usually two main authentication phases to consider:

1. Client-to-MCP Server authentication : This refers to the authentication of the MCP client (such as AI Agent) to the endpoint hosting the MCP Server on the Higress gateway. Higress provides a strong gateway-level authentication mechanism for this stage, such as Key Auth, JWT Auth, and OAuth2 support. These existing Higress features ensure that only authorized clients can access your MCP Server.
2. MCP Server to backend API authentication : Once an authorized client calls an MCP tool, the MCP Server plugin itself may need to authenticate to the final backend REST API proxied by the tool.

This release focuses on major enhancements to the second phase : providing comprehensive API authentication capabilities within the Higress MCP Server plug-in for its communication with the backend REST API. This update enables developers to manage credentials and authentication processes in a flexible and robust mechanism by configuring it in the MCP Server plug-in and following the OpenAPI standard, thereby securely integrating a wider range of backend services.

The following diagram illustrates these two authentication phases:

01

Overview of the newly added core authentication functions

This release introduces several core features to manage API authentication:

1. Reusable authentication schemes : Define common authentication methods (HTTP Basic, HTTP Bearer, API Key) at the server level.
2. Tool-specific backend authentication : Apply a defined authentication scheme to a single tool, specifying how the MCP Server should authenticate itself when calling the backend REST API.
3. Transparent credential passthrough : Allows credentials provided by MCP clients (such as AI assistants) to be securely passed through to the backend API.
4. Flexible credential management : Supports setting default credentials at the scenario level and allows overriding these default credentials for specific tools.

Next, let’s take a closer look at how to take advantage of these features.

02

Define an authentication scheme (server.securitySchemes)

You can now configure the server A level defines a set of securitySchemesThis approach aligns with the way security requirements are defined in the OpenAPI Specification (OAS3), making it easy to understand and standardize. Each scheme represents a specific authentication method that your backend API may use.

Currently, the Higress MCP Server plugin supports the following solution types:

• http Cooperate scheme: basic (HTTP Basic Authentication)
• http Cooperate scheme: bearer (HTTP Bearer Token Authentication)
• apiKey Cooperate in: header or in: query (API Key in the header or query parameter)

We plan to add support for oauth2 and openIdConnect (OIDC) scheme, further expanding the range of APIs you can securely integrate with.

securitySchemes Configuration fields :

Example :

server:
  name: my-secure-api-server
securitySchemes:
    - id: backendBasicAuth
      type: http
      scheme: basic
      defaultCredential: "service_user:p@$$wOrd"
    - id: backendBearerToken
      type: http
      scheme: bearer
      defaultCredential: "your_static_bearer_token_for_backend"
    - id: backendApiKeyHeader
      type: apiKey
      in: header
      name: X-Internal-ApiKey
      defaultCredential: "secret_backend_api_key"

03

Apply authentication for backend API calls (requestTemplate.security)

After defining the authentication scheme, you can apply it to the requests made by the MCP Server to the backend REST API. requestTemplate Configure in:

• requestTemplate.security.id: Cited in server.securitySchemes The scheme defined in id.
• requestTemplate.security.credential: (optional) allows you to override the backend call in the scheme for this particular tool defaultCredential.

Example :

tools:
  - name: fetch-sensitive-data
    description: "Get sensitive data from a backend service that requires a Bearer token."
    args: # ...
    requestTemplate:
      url: "https://api.internal.com/data"
      method: GET
      security:
        id: backendBearerToken # Use the 'backendBearerToken' scheme
        # credential: "override_token_for_this_tool_if_needed" # Override token for this tool if needed

04

Transparent Credentials Transmission

One of the most powerful new features is the ability to transparently pass credentials from client requests (e.g., from AI Agent to MCP Server) to backend API calls (MCP Server to the actual REST API). This capability is invaluable when the backend API requires user-specific authentication that the AI ​​client has.

Working principle:

1. Client authentication scheme definition : The MCP Server needs to know how the client authenticates. This is also done through server.securitySchemes is defined by a scheme in .
2. Tool-level security configuration  (tools[].security):
     ○ id: References the authentication scheme that the client should use when calling this MCP tool. The MCP Server will use this scheme to extract the client's credentials.

     ○ passthrough: true: This flag enables the passthrough mechanism.

3. Backend authentication : as described above requestTemplate.security Defines how pass-through credentials will be applied to backend API calls.

Example:

Suppose an AI client calls your MCP tool using a user-specific JWT Bearer token. You want to use the same token to call your backend service.

server:
  name: user-data-passthrough-server
securitySchemes:
    - id: clientUserBearer # The client passes the Bearer token
      type: http
      scheme: bearer
    - id: backendServiceBearer # The backend API solution (also Bearer, but can be different)
      type: http
      scheme: bearer
      # If you always rely on transparent transmission, you don't need defaultCredential here

tools:
- name: get-user-profile
    description: "Get a user profile using a token provided by the client."
    security: #Configuration of how the client authenticates to this MCP tool
      id: clientUserBearer # MCP Server expects the client to use the Bearer token   
      passthrough: true # Enable passthrough     
    args: # ...
    requestTemplate:
      url: "https://api.user-profiles.com/me"
      method: GET
      security: #Configure how MCP Server authenticates to the backend API
        id: backendServiceBearer # The transparent token will be sent to the backend as a Bearer token.

Workflow:

1. AI Client Calls get-user-profile tools and provide a Authorization: Bearer <user_jwt_token> Request header.
2. Higress MCP Server tools[].security.id: clientUserBearer extract <user_jwt_token>. The original from the client Authorization The request header is removed.
3. Due to the setting passthrough: true,<user_jwt_token> Specified as the credentials to use for backend calls.
4. Then, the MCP Server uses requestTemplate.security.id: backendServiceBearer The scheme defined in <user_jwt_token> and send it to https://api.user-profiles.com/me The endpoint (i.e., it sends Authorization: Bearer <user_jwt_token>).

Important notes about transparent transmission:

• when passthrough: true hour,requestTemplate.security.credential Any specified in credential will be ignored.
• MCP Server intelligently extracts the core credential part from the client request (for example, extracts the token from "Bearer token" and extracts the base64 part from "Basic base64value") and then transparently transmits it.

05

Benefits

These new authentication features provide:

• Enhanced security : Interactions with backend services are properly protected.
• Higher flexibility : Supports various common authentication modes.
• Simplified integration : Easier to integrate with APIs that have different security requirements.
• Seamless user context propagation : Transparently use the client-supplied credentials to make backend calls, enabling personalized API interactions.

We believe these enhancements will significantly improve the security posture and integration capabilities of AI-driven applications built with Higress and MCP Server.

06

pass openapi-to-mcp Simplified configuration

To further simplify the configuration process, the latest version of openapi-to-mcp The tool (project address: GitHub [1] ) now supports including securitySchemes The OpenAPI document defined in the MCP Server plugin is directly converted to this configuration. If your OpenAPI specification already describes its security requirements, the tool can generate the corresponding server.securitySchemes And link it to the appropriate tools, significantly reducing the workload of manual configuration.