4. Authentication and Security
The Hopex MCP Server is a HAS module. It therefore uses the same security framework as the other services exposed by Hopex Application Server.
Mode
Main use
User context
Secret
Recommended for
OAuth 2.0 / DCR
Interactive AI client usage
Authenticated Hopex user context
OAuth token and client registration
User-facing scenarios
API key
Machine-to-machine usage
Hopex user context associated with the API key
API key
Automation and technical integration
4.1. OAuth 2.0 and Dynamic Client Registration
The Hopex MCP Server supports OAuth 2.0 for interactive AI client usage. The AI client obtains an access token from the authentication service before calling the MCP endpoint exposed by HAS.
Dynamic Client Registration may be used when the AI client registers itself with the authentication service before the OAuth flow. Registration details are handled by the AI client and the authentication service; the Hopex MCP Server only consumes the validated authentication context.
The OAuth context includes the Hopex repository and connection profile. This binds the token to the correct Hopex environment and defines the applicable scope with the selected GraphQL schema and Hopex rights.
*The AI client registers dynamically when required, then starts the OAuth flow with the configured identity provider.
*After authentication and authorization, the AI client calls the MCP endpoint over HTTPS with the access token.
*HAS and the MCP Server validate the token and the associated OAuth context.
*The MCP Server accesses Hopex data through GraphQL/Web API within the authorized scope.
The OAuth configuration must remain aligned with the Hopex environment: identity provider, repository, connection profile, scopes, callback URLs, and client security rules.
OAuth declaration examples for AI clients are provided in section14.5 14.514.5 AI client configuration examples. They are indicative and depend on the AI client implementation and documentation.
4.2. API key authentication
API key mode supports calls without interactive authentication. Each API key is associated with a Hopex user context.
Mutation rules are defined in section Mutation authorization and governed operationally in section 13.4 Write-operation governance.
The AI client sends the API key in the x-api-key HTTP header. The declaration of this header depends on the AI client: connector configuration, environment variable, or dedicated administration screen.
The API key is managed as a secret. It is not exposed in code, logs, or user interfaces. Rotation, storage, and revocation follow the security rules of the customer environment.
Examples for x-api-key are provided in section 14.5 AI client configuration examples.
4.3. Authorization and Hopex rights
Authentication identifies the call context. Authorization then determines which data and operations are accessible. MCP calls use the Hopex rights associated with the target repository, connection profile, and exposed GraphQL schema.
The MCP Server exposes the authorized objects, relationships, and operations. The scope visible to the AI client depends on Hopex rights, HAS configuration, and the selected GraphQL schema.
4.4. Transport security
Communications with the MCP Server use HTTPS, like the other services exposed by HAS. HTTPS protects exchanges between the AI client, the MCP endpoint, HAS, and the exposed Hopex services.
Depending on the deployment, access may go through TLS termination, a reverse proxy, a gateway, firewall rules, and certificates. These elements follow the network and security rules of the customer environment.
4.5. Traceability
MCP calls are traced for diagnosis, support, and security analysis. Logs identify the call context, calling component, endpoint used, validation result, and any errors.
Logs remain compatible with confidentiality rules. They do not expose secrets, tokens, or API keys.
4.6. Licensing requirements
The Hopex MCP Server does not require a separate product license.
Each call uses the license and rights of the associated Hopex user: the authenticated user with OAuth, or the user linked to the API key. The API key can be linked to an existing user account or to a specific account created for API access. In the latter case, this account requires its own Hopex license.