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 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.
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.