Here is the translation and technical adaptation of your notes into English, organized for a technical troubleshooting guide.
1. State Consistency and Redirect URL
The MCP generates a state object that includes, among other data, the original redirect URI:
JSON
{
"session_id": "44e74c3d-d15e-45f8-8186-de28d48c923d",
"original_redirect_uri": "http://127.0.0.1:33418/"
}
The "Invalid Session" error typically occurs when the state reaches the /v1/callback endpoint, but the MCP cannot find a corresponding session for that session_id (or deems it invalid). This happens because:
The callback request is not hitting the same instance that initiated the flow.
A session header or cookie was lost or modified.
The callback body or URL was altered (e.g., the state was rewritten, or decoded/re-encoded differently).
Verification in Apigee:
Byte-for-byte Integrity: Ensure the state is passed identically to the backend:
No extra URL-decoding/encoding.
No truncation.
No query string reformatting.
Callback URL Origin: Verify if the client (VS Code) is using the Proxy URL or the direct MCP URL.
The MCP expects the callback at the exact URL registered and used at the start of the OAuth flow.
If the client is configured to use https://<proxy>/v1/callback but the MCP is internally registering a different URL, session failure may occur.
2. Preserving Session Cookies and Headers
Even if the OAuth flow is primarily stateless via the state parameter, many implementations maintain session state through:
Session Cookies: (e.g., Set-Cookie headers from the MCP returning in subsequent calls).
Session Identifiers: Tied to the state, which may include validation checks for IP address, User-Agent, etc.
Verification in Apigee:
Cookie Retention: Ensure cookies are not being stripped.
Check for AssignMessage or RemoveHeader policies that might be sanitizing cookies.
Confirm Set-Cookie from the MCP is reaching the client.
Confirm the session cookie is being sent back from the browser/VS Code to the proxy and forwarded to the MCP.
Header Preservation: Ensure critical headers are preserved:
Host, X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-For.
Some servers validate the expected scheme/host. If the MCP "expects" one host and the callback arrives with a different context, the session may be invalidated.
TLS Termination: If Apigee is terminating TLS and re-establishing a connection with the MCP, ensure X-Forwarded-* headers are accurate and no improper path rewriting (e.g., adding prefixes) is occurring.
Path and Host Rewriting in Apigee
Verify in Apigee:
Route Mapping: Ensure the mapping is correct.
Example: /v1/(.*) in Apigee → https://mcp.atlassian.com/v1/$1.
Ensure No Extra Path Suffixes: Confirm there is no unintended path manipulation (e.g., /mcp/v1/callback being mapped to /v1/callback or vice-versa, causing a mismatch between the client's request and the backend's expectation).
No Intermediate 302 Redirects: Check for any redirects that might drop the Query String (containing state and code).
2. Traffic Capture and Trace
Perform a test:
Capture via Apigee Trace: Log the incoming callback request from the client.
Capture Target Request: Log the request that Apigee forwards to https://mcp.atlassian.com.
Compare:
Exact Path: (e.g., /v1/callback).
Exact Query String: (state=...&code=...).
HTTP Headers: Specifically Cookies and the Host header.
Note: Any discrepancy in the state parameter or a missing cookie will likely result in an "Invalid Session" error.
3. Session Affinity & Load Balancing
If you are using multiple proxy instances or a Load Balancer (LB) in front of MCP:
Backend State: Check if the OAuth flow start (initial redirect) and the callback hit the same backend instance. This is critical if MCP does not use a shared session store.
Configuration:
Enable Sticky Sessions (Cookie or IP-based affinity) until the OAuth flow completes.
Alternatively: Confirm in the Atlassian MCP documentation if the service is fully stateless. The "Invalid Session" error strongly suggests that state is required.
4. Client Configuration (VS Code)
Check the MCP client settings in VS Code:
Base URL: Is it pointing to the proxy (e.g., https://meu-proxy.mydomain.com) or directly to https://mcp.atlassian.com?
Proxy Transparency: If pointing to the proxy, ensure the proxy is completely transparent.
Callback URL Mismatch: If there is any difference between the URL MCP registers as the callback at the start of the flow and the URL the Identity Provider (IdP) actually calls, the session will be rejected.
5. Suggested Diagnostic Tests
Test Without Rewriting: * Temporarily set up a "Pass-Through" proxy in Apigee with no extra policies or header manipulation.
Simply proxy https://<proxy>/ → https://mcp.atlassian.com/.
If this works, add policies back one by one to identify the breaking point.
Compare Direct vs. Proxy Traffic:
Use tools like Charles Proxy, Fiddler, or mitmproxy to compare a successful "Direct" callback with the "Proxied" one.
Verify Session Expiration:
Check if the proxy adds significant latency. If the time between the OAuth start and the callback exceeds the MCP session timeout, it will fail.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.