This topic provides minimal configuration examples for common deployment scenarios. These examples demonstrate how to configure authentication, authorization, TLS, and OAuth settings for the OpenEdge MCP Server. Use these examples as starting points and adapt them to your environment.
  • Read-only mode without authentication—The following example shows a minimal configuration for read-only mode without authentication.
    
{
  "api": {
    "openapi": {
      "spec_file": "openapi.yml"
    }
  },
  "security": {
       "authentication": {
      "enabled": false
    }
  }
}
  • Service account with scopes and TLS enabled—The following example shows a configuration for service account authentication with scopes and TLS.
    {
  "api": {
    "openapi": {
      "spec_file": "openapi.yml",
      "base_url": "https://api.example.com"
    }
  },
  "security": {
    "authentication": {
      "enabled": true,
      "service_account": {
        "enabled": true,
        "required": true,
        "header": "X-OEMCP-SERVICEACCOUNT",
        "issuer": "https://idp.example/realms/mcp",
        "jwks_uri": "https://idp.example/realms/mcp/protocol/openid-connect/certs",
        "required_scopes": [
          "mcp_access"
        ]
      },
      "user_auth": {
        "enabled": false
      }
    },
    "authorization": {
      "tools": {
        "default": [
          "mcp_access"
        ],
        "select_prompts": [
          "prompts.read"
        ]
      }
    }
  },
  "runtime": {
    "server": {
      "transport": {
        "tls": {
          "certfile": "./certs/server.pem",
          "keyfile": "./certs/server-key.pem"
        }
      }
    }
  }
}
    Note: Ensure both certfile and keyfile paths exist. If they are missing, the server will remain in HTTP mode.
  • OAuth SSO mode when client has an existing OAuth token—The following example shows a configuration for OAuth SSO mode.
    {
  "api": {
    "openapi": {
      "spec_file": "openapi.yml", 
      "base_url": "https://api.example.com"
    }
  },
  "security": {
    "authentication": {
      "enabled": true,
      "service_account": {
        "enabled": true,
        "required": true,
        "mode": "oauth",
        "sso_mode": true,
        "issuer": "http://localhost:8082/realms/mcp",
        "jwks_uri": "http://localhost:8082/realms/mcp/protocol/openid-connect/certs",
        "audience": "mcp-client", 
        "algorithms": ["RS256"],
        "required_scopes": ["mcp_access"]
      }
    },
    "authorization": {
      "tools": {
        "default": ["mcp_access"],
        "select_prompts": ["prompts.read"]
      }
    }
  }
}
    Note:
    • The MCP client already has an OAuth token from the identity provider.
    • The server validates the token and forwards the same token to downstream APIs.
    • No OAuth endpoints are provided because the client handles the OAuth flow externally.
  • OAuth2 standard configuration with proxy and SSO combined—The following example shows a configuration for OAuth2 standard mode with proxy and SSO combined.
    {
  "api": {
    "openapi": {
      "spec_file": "openapi.yml",
      "base_url": "https://api.example.com"
    }
  },
  "security": {
    "authentication": {
      "enabled": true,
      "service_account": {
        "enabled": true,
        "required": true,
        "mode": "oauth",
        "sso_mode": true,
        "issuer": "http://localhost:8082/realms/mcp",
        "jwks_uri": "http://localhost:8082/realms/mcp/protocol/openid-connect/certs",
        "client_id": "mcp-client",
        "client_secret": "your-client-secret-here",
        "audience": "mcp-client",
        "algorithms": ["RS256"],
        "required_scopes": ["mcp_access"],
        "advertised_scopes": ["openid", "profile", "email", "mcp_access"]
      }
    },
    "authorization": {
      "tools": {
        "default": ["mcp_access"],
        "select_prompts": ["prompts.read"]
      }
    }
  }
}
    Note:
    • This pattern combines proxy and SSO functionality.
    • The MCP server provides OAuth endpoints such as /authorize, /token, and /oauth/callback.
    • The client obtains a Keycloak token via the MCP server OAuth flow.
    • The same token is used for MCP calls and forwarded to downstream APIs.
    • The server exposes /.well-known/oauth-authorization-server for OAuth2 discovery.