🐞 Bug Summary

After completing the OAuth Authorization Code flow for an MCP gateway (e.g. redirect to IdP, sign-in, redirect back to /oauth/callback), the Fetch Tools action cannot be used successfully from the admin portal. Either the "🔧 Fetch Tools from MCP Server" button on the OAuth success page or the "🔧 Fetch Tools" button in the MCP Servers table results in a failed request. The backend returns 401 Unauthorized with the message "Cookie authentication not allowed for API requests. Use Authorization header." As a result, users cannot validate the token-delegation (on-behalf-of) flow or populate tools from the OAuth-protected MCP server directly from the UI.

🧩 Affected Component

Select the area of the project impacted:

• mcpgateway - API
• mcpgateway - UI (admin panel)
• mcpgateway.wrapper - stdio wrapper
• Federation or Transports
• CLI, Makefiles, or shell scripts
• Container setup (Docker/Podman/Compose)
• Other (explain below)

🔁 Steps to Reproduce

1. Log in to the Admin UI (e.g. https://<gateway-host>/admin) with a user that has permission to manage gateways.
2. Open MCP Servers (Gateways) and create or edit a gateway with Authentication Type: OAuth 2.0, Grant Type: Authorization Code (User Delegation), and valid Token URL, Authorization URL, Redirect URI, and Scopes (e.g. Microsoft Entra ID or another OAuth provider).
3. Click Authorize (or equivalent) for that gateway. Complete the IdP sign-in and consent so the browser is redirected back to the gateway’s Redirect URI (e.g. https://<gateway-host>/oauth/callback?code=...&state=...).
4. On the OAuth Authorization Successful page, click "🔧 Fetch Tools from MCP Server".
5. Alternatively, from the Admin UI go to MCP Servers, locate the same OAuth gateway, and click "🔧 Fetch Tools" in the actions column.
6. Observe the result: the request to POST /oauth/fetch-tools/<gateway_id> returns 401, and the UI shows an error such as "Cookie authentication not allowed for API requests. Use Authorization header." (or the button appears to do nothing if the client does not send credentials).

🤔 Expected Behavior

The portal should allow testing Fetch Tools after OAuth has been completed. The browser should send the user’s session (e.g. JWT) in a way the backend accepts—for example via the Authorization: Bearer <token> header when calling POST /oauth/fetch-tools/{gateway_id}. The backend should authenticate the request, retrieve the stored OAuth tokens for that gateway and user, call the MCP server with the delegated access token, and return success (or a clear MCP/network error). The UI should show a success message and/or updated tools, or a user-friendly error message—not a 401 due to cookie-based auth being rejected for this endpoint.

📓 Logs / Error Output

Paste any relevant stack traces or logs here.
⚠️ Do not paste secrets, credentials, or tokens.

Structured log (anonymized):

{
  "levelname": "WARNING",
  "message": "[http_gateway] Request completed: POST /oauth/fetch-tools/<gateway_id> - 401",
  "request_method": "POST",
  "request_path": "/oauth/fetch-tools/<gateway_id>",
  "response_status_code": 401,
  "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36"
}

Uvicorn access log (anonymized):

<client_ip>:0 - "POST /oauth/fetch-tools/<gateway_id> HTTP/1.1" 401

UI (user-facing):

• OAuth success page: "❌ Failed to Fetch Tools" with "Error: Cookie authentication not allowed for API requests. Use Authorization header."
• Admin gateways table: Button may show "⏳ Fetching..." then "❌ Retry" with a similar error in a toast or message area.

🧠 Environment Info

You can retrieve most of this from the /version endpoint.

🧩 Additional Context (optional)

• Root cause (for maintainers): The endpoint POST /oauth/fetch-tools/{gateway_id} is protected by the same auth dependency as other API routes. The RBAC/auth middleware rejects requests that authenticate only via cookie when the request is not classified as a "browser" request (e.g. Accept does not include text/html, or Referer does not contain /admin). The OAuth success page is served at /oauth/callback; when the user clicks "Fetch Tools" from that page, the fetch() request has a referer like .../oauth/callback?..., so the middleware treats it as an API request and requires the Authorization header. The inline script and the gateways-table handler previously did not send the JWT from the cookie in the Authorization header, so the server returned 401.
• Flow impacted: This is the token delegation (on-behalf-of) flow: the user authorizes once, the gateway stores OAuth tokens per (gateway_id, app_user_email), and "Fetch Tools" uses that stored token to call the MCP server and sync tools. If Fetch Tools cannot be exercised from the portal, users cannot verify the full OAuth → token storage → MCP call pipeline from the UI.
• Gateway config (anonymized): Transport e.g. Streamable HTTP; Auth Type OAuth 2.0; Authorization Code; Token URL and Authorization URL point to a well-known OAuth2/OpenID provider; Redirect URI is the gateway’s /oauth/callback; Scopes include a scope such as user_impersonation or similar for delegated access.
• Possible workaround (not a fix): Calling POST /oauth/fetch-tools/{gateway_id} with an Authorization: Bearer <gateway_jwt> header (e.g. from curl or another client) can succeed if the gateway JWT is valid and the user has completed OAuth for that gateway.