Authentication headers and access information
- Last Updated: December 23, 2025
- 1 minute read
- OpenEdge
- Version 12.8
- Documentation
Authentication headers and tokens ensure secure communication between the MCP client and server. Proper configuration prevents unauthorized access and enforces security policies. Using mTLS adds an extra layer of trust by validating client certificates.This topic explains how authentication headers are used in OpenEdge MCP client-server communication.
Service account authentication
| Header | Value | Notes |
|---|---|---|
X-OEMCP-SERVICEACCOUNT |
JWT | Required for service account authentication |
generated/<profile_name>/client/client.env
under SERVICE_ACCOUNT_JWT=.Token selection priority for mcpgen client command
| Priority | Source | Description |
|---|---|---|
| 1 | --sa-token NAME |
Uses specific token file
client/sa.<name>.jwt (highest
priority) |
| 2 | $SERVICE_ACCOUNT_JWT |
Environment variable override |
| 3 | client.env | Default token from file |
remint-all.User token authentication
Authorization header
of the HTTP request. The format is:
|
mTLS requirement
Mutual TLS (mTLS) provides an additional security layer by requiring both the client and
server to present valid certificates during the TLS handshake. This ensures that
only trusted clients can communicate with the server. When you use the
--mtls option, the client must supply a valid certificate
recognized by the certificate authority (CA) generated by the MCP tools. The CA and
related scripts are located in the certs/ directory. If you are
using the containerized utilities client with generated artifacts, mTLS
configuration is handled automatically.