Gateway missing MCP OAuth spec endpoints (RFC 8414, RFC 7591) - blocks Claude Desktop/claude.ai connector integration

[nhasanli]

Description

The AgentCore MCP Gateway does not implement the OAuth endpoints required by the MCP Authorization Specification. This prevents MCP clients like Claude Desktop and claude.ai from connecting without manually providing OAuth client credentials.

What's Missing

1. OAuth Authorization Server Metadata (RFC 8414)

curl https://{gateway}.gateway.bedrock-agentcore.us-east-1.amazonaws.com/.well-known/oauth-authorization-server
# Returns: <UnknownOperationException/>

The MCP spec requires servers to expose /.well-known/oauth-authorization-server so clients can discover the authorization and token endpoints. The Gateway only exposes /.well-known/oauth-protected-resource (RFC 9728), which correctly points to Cognito, but Cognito itself doesn't serve RFC 8414 metadata (only OIDC discovery).

2. Dynamic Client Registration (RFC 7591)

curl -X POST https://{gateway}.gateway.bedrock-agentcore.us-east-1.amazonaws.com/register \
  -H "Content-Type: application/json" \
  -d '{"client_name":"claude-desktop","redirect_uris":["https://claude.ai/api/mcp/auth_callback"]}'
# Returns: {"Output":{"__type":"com.amazon.coral.service#UnknownOperationException"}}

The MCP spec requires servers to support Dynamic Client Registration so MCP clients can automatically obtain OAuth credentials. Without this, users must manually configure client_id and client_secret when adding the connector.

Impact

Claude Desktop and claude.ai support MCP OAuth (both 3/26 and 6/18 specs) with Dynamic Client Registration. The expected user experience is:

1. User pastes Gateway MCP URL into Claude Settings > Connectors
2. Claude auto-discovers OAuth config and registers itself
3. User authenticates via federated IdP (e.g., Google Workspace)
4. Done

Current experience: Users must manually obtain and enter Cognito client_id and client_secret in Claude's "Advanced settings." This defeats the purpose of a managed gateway and makes it impractical for non-technical users.

What the Gateway Should Do

The Gateway should proxy the OAuth discovery and registration endpoints to/from the configured Cognito user pool:

1. /.well-known/oauth-authorization-server - Return RFC 8414 metadata derived from Cognito's OIDC discovery, including a registration_endpoint
2. /register (POST) - Accept RFC 7591 registration requests, create a Cognito app client with the provided redirect URIs, and return the client credentials

This would make any AgentCore Gateway instantly compatible with Claude and other MCP clients that implement the spec.

Environment

• Region: us-east-1
• Gateway auth: CUSTOM_JWT with Cognito user pool
• Cognito IdP: Google (Workspace federation)
• MCP client: Claude Desktop / claude.ai

Related

• Gateway mcpServer target to AgentCore Runtime: JWT-auth sessions start but requests never reach container #1030 (Gateway → Runtime JWT auth bug)

[dgallitelli]

Independent Validation — Confirmed with Nuance

I reproduced this against two live AgentCore Gateways (us-east-1) with CUSTOM_JWT auth backed by Cognito. Here's what I found.

Test Results

Test	Endpoint	Result
RFC 9728 (Protected Resource Metadata)	GET /.well-known/oauth-protected-resource on Gateway	✅ 200 — returns authorization_servers + resource URI
401 + WWW-Authenticate	POST /mcp without Bearer token	✅ 401 with WWW-Authenticate: Bearer resource_metadata="..."
RFC 8414 (AS Metadata)	GET /.well-known/oauth-authorization-server on Gateway	❌ 404 <UnknownOperationException/>
RFC 8414 (AS Metadata)	GET /.well-known/oauth-authorization-server on Cognito	❌ 400 BadRequest
RFC 7591 (DCR)	POST /register on Gateway	❌ 403 / UnknownOperationException
OIDC Discovery	GET /.well-known/openid-configuration on Cognito	✅ 200 — returns all OAuth endpoints

Raw Evidence

# Gateway correctly serves RFC 9728
$ curl https://{gateway}.gateway.bedrock-agentcore.us-east-1.amazonaws.com/.well-known/oauth-protected-resource
{"authorization_servers":["https://cognito-idp.us-east-1.amazonaws.com/us-east-1_XXXXX"],
 "resource":"https://{gateway}.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp"}

# Gateway correctly returns 401 with resource_metadata pointer
$ curl -X POST https://{gateway}.../mcp -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"initialize","id":1}'
# HTTP 401
# www-authenticate: Bearer resource_metadata="https://{gateway}.../.well-known/oauth-protected-resource"

# RFC 8414 fails on BOTH Gateway and Cognito
$ curl https://{gateway}.../.well-known/oauth-authorization-server
<UnknownOperationException/>   # 404

$ curl https://cognito-idp.us-east-1.amazonaws.com/us-east-1_XXXXX/.well-known/oauth-authorization-server
{"code":"BadRequest","message":"The server did not understand the operation that was requested."}  # 400

# Cognito only serves OIDC discovery (not RFC 8414)
$ curl https://cognito-idp.us-east-1.amazonaws.com/us-east-1_XXXXX/.well-known/openid-configuration
# 200 — returns authorization_endpoint, token_endpoint, etc. (no registration_endpoint)

Analysis: The Issue Is Real But the Responsibility Is Split

The original issue frames this as the Gateway missing RFC 8414 and RFC 7591. That's half right. Under the MCP 2025-06-18 spec, the architecture separates roles:

• Resource Server (the Gateway): MUST serve RFC 9728 metadata → ✅ Gateway does this correctly
• Authorization Server (Cognito): MUST serve RFC 8414 metadata → ❌ Cognito does NOT do this

The Gateway is correctly fulfilling its Resource Server role. The chain breaks because Cognito only serves OIDC Discovery (/.well-known/openid-configuration) and not RFC 8414 (/.well-known/oauth-authorization-server). These are different specs — OIDC Discovery predates RFC 8414, and while they contain similar data, MCP clients implementing the 2025-06-18 spec strictly will look for RFC 8414 and fail.

For DCR: Cognito doesn't expose a registration_endpoint in its OIDC discovery, and doesn't support RFC 7591 at all. This is a Cognito limitation, not a Gateway one.

Impact on Claude Desktop / claude.ai

The MCP OAuth flow for Claude goes:

1. POST /mcp → 401 + WWW-Authenticate → ✅ works
2. GET /.well-known/oauth-protected-resource → discovers Cognito as AS → ✅ works
3. GET /.well-known/oauth-authorization-server on Cognito → ❌ breaks here
4. DCR at /register → ❌ not available anywhere

The 2025-03-26 spec had fallback defaults (/authorize, /token, /register relative to AS base URL) when RFC 8414 was absent. The 2025-06-18 spec removed those fallbacks — metadata discovery is now mandatory. So whether Claude's flow succeeds depends on which spec version it's implementing and whether it falls back to OIDC discovery.

Claude Desktop does support manual client_id/client_secret entry in Advanced Settings, which is the current workaround — but as the issue author notes, this defeats the managed gateway UX.

Suggested Fix

The original issue's proposed solution (Gateway proxies RFC 8414 + DCR) is actually the most practical path since Cognito won't add RFC 8414 support anytime soon:

1. /.well-known/oauth-authorization-server on the Gateway → synthesize RFC 8414 response by fetching Cognito's OIDC discovery and mapping it to RFC 8414 format (they're structurally very similar)
2. /register on the Gateway → proxy to Cognito's CreateUserPoolClient API and return RFC 7591 response

There's also a community solution that adds a Lambda-backed DCR endpoint as a workaround.

Verdict

Issue confirmed. The Gateway's RFC 9728 implementation is correct per the 2025-06-18 spec, but the end-to-end MCP OAuth flow is broken because Cognito doesn't implement RFC 8414. The Gateway is the natural place to bridge this gap since it controls the MCP endpoint and knows which AS it's configured with.

Reproduction Commands (PII-free)

# Replace these placeholders with your own values
GATEWAY_BASE="https://{your-gateway-id}.gateway.bedrock-agentcore.{region}.amazonaws.com"
COGNITO_ISSUER="https://cognito-idp.{region}.amazonaws.com/{your-user-pool-id}"

# ── Test 1: RFC 9728 — Protected Resource Metadata (expected: 200) ──
curl -s -w "\nHTTP_STATUS: %{http_code}\n" \
  "$GATEWAY_BASE/.well-known/oauth-protected-resource"

# ── Test 2: RFC 8414 — OAuth AS Metadata on Gateway (expected: 404) ──
curl -s -w "\nHTTP_STATUS: %{http_code}\n" \
  "$GATEWAY_BASE/.well-known/oauth-authorization-server"

# ── Test 3: RFC 7591 — Dynamic Client Registration on Gateway (expected: 403) ──
curl -s -w "\nHTTP_STATUS: %{http_code}\n" -X POST \
  "$GATEWAY_BASE/register" \
  -H "Content-Type: application/json" \
  -d '{"client_name":"test-client","redirect_uris":["http://localhost:3000/callback"],"grant_types":["authorization_code"],"token_endpoint_auth_method":"none"}'

# ── Test 4: Unauthenticated MCP request — check 401 + WWW-Authenticate (expected: 401) ──
curl -s -D - -X POST "$GATEWAY_BASE/mcp" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"initialize","id":1,"params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0.0"}}}'

# ── Test 5: Cognito OIDC Discovery (expected: 200) ──
curl -s -w "\nHTTP_STATUS: %{http_code}\n" \
  "$COGNITO_ISSUER/.well-known/openid-configuration"

# ── Test 6: RFC 8414 — OAuth AS Metadata on Cognito (expected: 400) ──
curl -s -w "\nHTTP_STATUS: %{http_code}\n" \
  "$COGNITO_ISSUER/.well-known/oauth-authorization-server"

[massi-ang]

@nhasanli you can check these samples to setup Gateway for connections with 3rd party clients requiring DCR: https://github.com/awslabs/agentcore-samples/tree/main/01-tutorials/02-AgentCore-gateway/04-integration/04-enterprise-mcp-demo