Problem
When developers integrate MCP servers using Scalekit OAuth (bring-your-own-auth), certain MCP clients (including Amazon Q) use a popup-based OAuth flow. If the app's login page sets Cross-Origin-Opener-Policy: same-origin, the browser severs the opener reference from the popup as soon as the login page loads. The MCP client sees popup.closed === true immediately and reports an error — even though the OAuth flow itself succeeds.
This is standard browser COOP enforcement and is not a Scalekit bug, but it produces a confusing failure with no actionable error message for developers.
Root cause (confirmed)
Cross-Origin-Opener-Policy: same-origin
When a cross-origin window (e.g., quick.aws.com) opens a popup that navigates to a page with COOP: same-origin, the browser severs the opener's reference to the popup. The MCP client's popup reference becomes closed === true immediately, before the OAuth flow completes.
Fix (app-side): Remove or change COOP to unsafe-none on the login/redirect endpoint used in the OAuth callback path.
What the docs should cover
Add a troubleshooting section to the MCP OAuth documentation covering:
- Symptom: OAuth popup closes immediately or "window closed too soon" error appears in the MCP client, even though the auth flow appears to complete.
- Diagnosis: Check
Cross-Origin-Opener-Policy header on the app's login page via curl -sI <login-url> | grep -i cross-origin.
- Fix: Set
Cross-Origin-Opener-Policy: unsafe-none on the login/redirect endpoint, or scope the COOP header only to non-OAuth paths.
- Note: This is a browser security policy enforced by the customer's app, not a Scalekit configuration issue.
Suggested doc location
src/content/docs/agentkit/ — MCP server OAuth integration guide (troubleshooting section)- Possibly a dedicated troubleshooting page for MCP auth
Additional context
The same issue surfaced alongside a separate email claim regression (a platform-side configuration that caused email to disappear from access tokens). The two are unrelated but both blocked the same integration. The email claim issue was resolved by support; the COOP issue required the customer to update their app's HTTP headers.
Source
Resolved support conversation — Slack thread about OAuth connection failure in Amazon Q when connecting to an MCP server using Scalekit auth. 25-message thread with 2+ day resolution time.
Problem
When developers integrate MCP servers using Scalekit OAuth (bring-your-own-auth), certain MCP clients (including Amazon Q) use a popup-based OAuth flow. If the app's login page sets
Cross-Origin-Opener-Policy: same-origin, the browser severs the opener reference from the popup as soon as the login page loads. The MCP client seespopup.closed === trueimmediately and reports an error — even though the OAuth flow itself succeeds.This is standard browser COOP enforcement and is not a Scalekit bug, but it produces a confusing failure with no actionable error message for developers.
Root cause (confirmed)
When a cross-origin window (e.g.,
quick.aws.com) opens a popup that navigates to a page withCOOP: same-origin, the browser severs the opener's reference to the popup. The MCP client's popup reference becomesclosed === trueimmediately, before the OAuth flow completes.Fix (app-side): Remove or change
COOPtounsafe-noneon the login/redirect endpoint used in the OAuth callback path.What the docs should cover
Add a troubleshooting section to the MCP OAuth documentation covering:
Cross-Origin-Opener-Policyheader on the app's login page viacurl -sI <login-url> | grep -i cross-origin.Cross-Origin-Opener-Policy: unsafe-noneon the login/redirect endpoint, or scope the COOP header only to non-OAuth paths.Suggested doc location
src/content/docs/agentkit/— MCP server OAuth integration guide (troubleshooting section)Additional context
The same issue surfaced alongside a separate email claim regression (a platform-side configuration that caused
emailto disappear from access tokens). The two are unrelated but both blocked the same integration. The email claim issue was resolved by support; the COOP issue required the customer to update their app's HTTP headers.Source
Resolved support conversation — Slack thread about OAuth connection failure in Amazon Q when connecting to an MCP server using Scalekit auth. 25-message thread with 2+ day resolution time.