{
  "id": 2000172,
  "title": "The Cognito war stories: four ways it breaks an MCP server, and the fix for each",
  "url": "https://urgent.news/2026/08/19/the-cognito-war-stories-four-ways-it-breaks-an-mcp-server-and-the-fix",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-19T19:05:33.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/akashy/the-cognito-war-stories-four-ways-it-breaks-an-mcp-server-and-the-fix-for-each-2fim"
  },
  "original_language": "en",
  "account": "Four ways Amazon Cognito can break an MCP server, along with solutions for each issue:\n\n1. Cognito rejects RFC 8707 resource indicators sent by MCP:\n- When using an agent OAuth flow for Cognito, MCP sends access tokens with audience-bound parameters. However, Cognito does not support RFC 8707 and rejects requests with unrecognized parameters.\n- This issue occurs at the first hop when the user is redirected to Cognito's /authorize endpoint, preventing the user from seeing the login box.\n- The solution is to implement a thin, same-origin OAuth proxy in front of Cognito's /authorize and /token endpoints. The proxy should strip the resource parameter while preserving other necessary claims, such as code_challenge, to avoid breaking PKCE.\n\n2. Cognito access tokens lack the aud claim:\n- Access tokens issued by Cognito do not contain the aud claim, which is used for audience validation. This makes audience validation more challenging compared to ID tokens.\n- MCP servers must validate that access tokens are issued specifically for them as the intended audience, as per RFC 8707 Section 2.\n- To satisfy MCP requirements, audience validation should be implemented based on the client_id and token_use fields present in Cognito access tokens. Compare the client_id against the configured client and ensure token_use equals \"access.\"\n\n3. Managed Login v2 requires client branding styles:\n- When switching to Managed Login (version-2 hosted UI) and configuring a new app client, users may encounter the error message \"Login pages unavailable. Please contact an administrator.\"\n- The issue arises because Managed Login will not render a login page for a client that lacks a branding style. Unlike the web client, which inherits a default style, the newly-added agent client does not have a branding style applied.\n- The fix is to assign a branding style to every client, even if it is a near-clone of another client's style. In Terraform, this can be achieved using the awscc_cognito_managed_login_branding resource (or the equivalent v6 resource). Ensure the branding resource is configured for the agent client, providing a matching palette and logo assets.",
  "summary": "If you are putting Amazon Cognito behind a remote MCP server, here are four specific ways it will break the connector before you ever reach your own code - each with the symptom, the reason, and the fix that got us through it. All four came out of one week of wiring an agent OAuth flow for cogDepot , and none of them are in the happy-path docs. None of this is competitively sensitive. It is just…",
  "key_points": [
    "Cognito rejects RFC 8707 resource indicators, breaking MCP server authentication",
    "Cognito access tokens lack aud claim, complicating audience validation",
    "Managed Login v2 requires client branding styles, causing login page unavailability"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}