How is your experience with the OutSystems Community?
7
Views
0
Comments
[MCP Server] 1.0.2 upgrade breaks existing MCP connections: JWT setup and renewal undocumented
mcp-server
Reactive icon
Forge asset by Mediaweb
Application Type
Reactive

Hi team,


After upgrading a working MCP Server installation to version 1.0.2, our existing MCP client connection stopped working immediately. The initial initialize request returned HTTP 401 with "Invalid authorization", before the client could discover or call any tools.


Our use is internal and controlled. The tools already have API keys configured for the internal calls. We understand that authentication at the MCP endpoint is a separate layer; our concern is the breaking change and the missing migration instructions.


In the previous version, the server checked only Site.MCPServer_BearerToken, and even worked with ""


In 1.0.2, do some JWT implementation, but we checked the Forge overview/release notes and documentation, as well as the Documentation and Installation Guide pages included in the application. We could not find instructions explaining this authentication change or how to configure and manage it.


Could you please document:


1. The migration path from the previous Bearer-token check, including the fact that existing connections can fail immediately after upgrading.

2. How to configure Auth_SignatureKey, Auth_SignatureKeyId, Auth_ExpectedIssuer and Auth_ExpectedAudience, including their intended use when one environment hosts several MCP servers.

3. How and where clients should obtain a signed JWT, and how to configure clients such as Codex and Claude to send it.

4. What happens when the JWT expires, and the supported mechanism for issuing/renewing tokens automatically. We did not find a token issuance or refresh endpoint in MCPServer_Auth.

5. How to troubleshoot validation failures beyond the generic 401 response.


We confirmed that a correctly signed JWT allows initialize and call tools to succeed. However, with no time to investigate and implement an ongoing token lifecycle, we temporarily restored the previous authentication check for our controlled internal installation. Direct access then worked again.


Could you clarify the intended authentication setup for 1.0.2 and provide a complete configuration and token-renewal example? A clear breaking-change warning in the release notes would also help existing users prepare before upgrading.


Thank you.
Carlos Oliveira

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.