Loading today’s stories
Build1 distinct publisher3 min readUpdated
A dev.to writeup documents Amazon Cognito killing a spec-compliant MCP connector at the first redirect, and the only fix on offer is a proxy that strips one parameter and nothing else.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A writeup published on dev.to documents Amazon Cognito refusing the first request a spec-compliant MCP client makes: Cognito does not implement RFC 8707 Resource Indicators, and rather than ignoring the `resource` parameter it rejects the request for carrying an unrecognized parameter [2]. According to that account, the redirect to `/authorize` dies before the user is shown a login box [3], which means a team standardizing agent OAuth on Cognito has no working flow at hop one.
The collision is structural. MCP's authorization spec wants access tokens audience-bound, and the mechanism it points at is RFC 8707: the client appends a `resource` parameter to `/authorize` and `/token` naming the server it wants a token for, and the authorization server binds the issued token to that resource [1]. A spec-compliant client sends it unconditionally, Claude's connector included, and the author notes you do not get to switch it off from the client side [4]. There is also no Cognito setting that accepts or ignores the parameter [5]. Both ends are fixed, so anything that makes this work has to sit between them [18].
The fix described is a thin, same-origin OAuth proxy in front of Cognito's `/authorize` and `/token`, forwarding everything through untouched except for stripping `resource` on the way in [6]. The warning attached to it is the useful part: strip `resource` and nothing else, because `code_challenge` and `code_challenge_method` have to survive verbatim or you break PKCE and trade one failure for another [7]. The author's verification checklist encodes exactly that, as "/oauth/authorize strips the RFC 8707 resource param while preserving code_challenge" [8].
Stripping the parameter also strips the guarantee. The audience binding RFC 8707 was supposed to provide now has to be enforced at the resource server [9], and MCP's language is not soft about it: servers MUST validate that access tokens were issued specifically for them as the intended audience, per RFC 8707 Section 2, and MUST NOT accept or transit any other tokens [10].
Here Cognito diverges again from habit. A Cognito access token has no `aud` claim at all; the client it was minted for is named in `client_id`, and the token carries `token_use: access` where an ID token carries `token_use: id` [11]. So the check that satisfies the MCP requirement is a `client_id` comparison against your configured client plus a requirement that `token_use` equals `access` [12]. Skip the `token_use` check and an ID token minted for the same client sails through the access-token path [13]. Skip the `client_id` check and any access token from the same user pool is accepted as yours, including one issued to a completely different app client [14]. The author's framing is worth keeping: the pool is the trust boundary Cognito gives you for free, the client is the one you have to draw yourself [15]. Alongside that, pin one algorithm and one key type, RS256 and RSA, compared against the values in the attacker-supplied token header rather than inferred from it, since algorithm confusion needs a negotiable `alg` field to exist [16].
Watch whether Cognito ever accepts or ignores `resource`, because until it does, every MCP deployment behind it carries a hand-written proxy in the auth path. This is one team's week of work on a project called cogDepot, and the author says none of it appears in the happy-path docs [17]; treat the checklist as a starting point for your own tests, not as coverage.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
MCP's authorization spec wants access tokens to be audience-bound, and the mechanism it points at is RFC 8707 Resource Indicators: the client appends a resource parameter to the /authorize and /token requests naming the server it wants a token for, and the authorization server is supposed to bind the resulting token to that resource.
Cognito does not implement RFC 8707. It does not bind the token to the resource; it rejects the request for carrying an unrecognized parameter.
The connector's first hop, the redirect to /authorize, dies before the user ever sees a login box.
A spec-compliant MCP client sends the resource parameter unconditionally; Claude's connector does, and it cannot be turned off from the client side.
The fix is a thin, same-origin OAuth proxy sitting in front of Cognito's /authorize and /token, which forwards everything through untouched except that it strips the resource parameter on the way in.
The proxy must strip resource and nothing else; in particular code_challenge and code_challenge_method have to survive verbatim, or PKCE breaks and one failure is traded for another.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed first-hand account, single source, no independent reproduction
The claims are unusually specific for a single-source story: verbatim MCP spec language, a named RFC, the exact parameter at fault, a trimmed verifier with the three claim checks, and a stated proxy verification checklist. But every assertion traces to one dev.to write-up by one practitioner; no AWS documentation, no second implementer, and no reproduction artifact is present in the cluster, and the strongest claim (no Cognito configuration can tolerate the parameter) is asserted rather than demonstrated.
One disclosed deployment plus one observed client behaviour
Adoption evidence is limited to the author's own cogDepot integration and the observed behaviour of Claude's MCP connector sending the resource parameter. There are no user counts, downloads, repository references, multiple operators, or vendor statements in the supplied material, so the pattern is demonstrated once rather than shown to be widespread.
Sober practitioner framing, mildly under-stated stakes
The write-up avoids promotional language, discloses provenance, and confines itself to symptom/reason/fix; if anything the security consequences of stripping a spec-mandated audience binding and hand-rolling the substitute check are understated relative to how easily an operator could omit token_use or client_id. The small positive pull in the other direction is the unqualified 'cannot be fixed' generalisation from a single week of testing, so the net gap is close to aligned.
Self-published practitioner post referencing the author's own project
The author writes on a self-publishing platform about their own project, cogDepot, which creates mild visibility and credibility incentives, and the recommended fix is the author's own architecture. Offsetting this, the post disclaims competitive sensitivity, sells nothing, names no sponsor, and criticises no competitor's product for commercial advantage; nothing in the cluster indicates vendor funding or coordinated messaging.
Coherent and checkable, but wholly unreplicated
Internal consistency is high and the mechanisms described are independently checkable in principle (a documented RFC, quoted spec MUSTs, and claim-level token semantics), which supports moderate confidence in the mechanics. Confidence is held down by the single-publisher cluster, the absence of versions, dates, or region details for the Cognito behaviour, and one claim marked insufficient.
build
Atlas App Connections hands AI clients your whole Atlas role, so fix the roles first1 distinct publisher
build
Decoys in the .env file: Jitpass bets on lying to your coding agent1 distinct publisher
build
Rate limit your MCP servers, because a retrying agent turns one error into a billing incident1 distinct publisher
product
A 2x LLM bill is not a bug report: token spend is an observability problem1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 19, 2026