MCP Connector — Cannot switch from User OAuth to Service-to-Service OAuth for scheduled Flows (valid credentials rejected by Quick)

[bindaly]

Hi Quick Community,

Posting this to see if anyone has run into a similar issue or has guidance. Detailed write-up below.

---

What We’re Trying to Do

We have an MCP connector in Amazon Quick that connects to a Bedrock AgentCore gateway. We want to use this connector in scheduled Flows that run automatically on a set day/time without any manual intervention.

---

The Problem

The connector is currently configured with Custom User-Based OAuth (3LO). This works fine for interactive use (Chat, Q Apps, Dashboards), but breaks for scheduled Flows because:

• User OAuth requires an interactive sign-in via browser
• OAuth tokens expire periodically (~90-day refresh token lifecycle)
• When a scheduled Flow triggers, there’s no user present to re-authenticate
• The Flow hangs indefinitely waiting for sign-in, or fails outright

Bottom line: User-Based OAuth is fundamentally incompatible with unattended/scheduled automation.

---

The Solution We’re Pursuing

Switch to Service-to-Service OAuth (2LO / client credentials grant), which:

• Authenticates using client credentials (Client ID + Secret) — no user interaction needed
• Tokens auto-refresh via the client credentials flow
• Designed specifically for automated workflows and background processes

We understand that MCP servers cannot advertise Service-to-Service OAuth via the protocol’s auto-discovery mechanism (DCR / RFC 9728), and that it must be manually configured on the Quick connector side.

---

What We’ve Tried

Attempt 1: Edit existing connector

• Went to More → Connectors → Edit on the existing MCP connector
• On Step 2 (Authenticate), the Auth configuration dropdown only shows “Custom user based OAuth”
• No option to switch to Service-to-Service OAuth

Attempt 2: Create a new integration with Service authentication

• Created a new integration for the same MCP server
• Selected Service authentication → Service-to-Service OAuth
• Entered Client ID, Client Secret, and Token URL
• Clicked “Create and continue”
• Got error: “One or more parameters are invalid. Please review your input”

Attempt 3: Independent credential validation

• To rule out bad credentials, we tested the exact same parameters via cURL from terminal:

curl -X POST <token_url> \
  -d "grant_type=client_credentials" \
  -d "client_id=<client_id>" \
  -d "client_secret=<client_secret>"

• Result: SUCCESS — Valid access_token returned (bearer token, 900s expiry)
• This confirms:
  • Client ID is correct
  • Client Secret is valid and not expired
  • Token URL is correct and reachable
  • Identity provider supports client_credentials grant type

So the credentials are 100% valid — Quick is rejecting them during connector creation.

---

Our Analysis

What	Status
Client ID	Valid (confirmed via cURL)
Client Secret	Valid (confirmed via cURL)
Token URL	Reachable and correct (confirmed via cURL)
client_credentials grant	Supported by identity provider
Quick connector validation	Rejects valid credentials

The issue is clearly on the Quick connector validation side, not with the OAuth parameters or the identity provider.

---

Our Questions for the Community

1. Has anyone successfully configured Service-to-Service OAuth for an MCP connector in Quick? If so, what was your setup? Any special steps?

2. Does the MCP server / Bedrock AgentCore gateway need specific configuration to allow Quick to offer Service-to-Service OAuth as an option? Is there a server-side declaration or metadata that Quick checks before allowing this auth type?

3. Is there a hidden/required parameter (e.g., scope, audience, or custom headers) that Quick expects for Service-to-Service OAuth but doesn’t expose in the UI?

4. Is this a known limitation for MCP connectors backed by Bedrock AgentCore? Does Quick currently support Service-to-Service OAuth for all MCP connectors, or only for specific connector types?

5. Workaround suggestions? If Service-to-Service OAuth isn’t directly supported for MCP connectors, has anyone successfully used an alternative approach (e.g., fronting with Amazon Cognito, API Gateway with a client_credentials authorizer) to enable unattended automation?

---

Summary

Aspect	Detail
Connector type	MCP (Bedrock AgentCore gateway)
Current auth	Custom User-Based OAuth (3LO)
Desired auth	Service-to-Service OAuth (2LO)
Use case	Scheduled Flows (unattended automation)
Blocker	Quick rejects valid Service-to-Service OAuth credentials during integration creation
Credentials validated?	Yes — via cURL, access token returned successfully

---

Any guidance, similar experiences, or workarounds would be greatly appreciated. Happy to provide more details if needed.

Thanks!

[JacobR]

Hi @bindaly and welcome to the Quick Community!

From what I can research, nothing on the Gateway side has to advertise Service-to-Service OAuth. You choose it when you create the connector, which is why it appeared on your new integration but not under Edit. The console won’t switch an existing connector’s auth type, so a new connector is the way to go. AWS’s Runtime walkthrough sets one up with just a Client ID, secret and Token URL, and the Gateway walkthrough points to Service authentication for more systematic integrations. Once it exists, add the new client ID to your Gateway’s inbound authorizer allowed clients if that list is in use, and make sure any allowed audiences or scopes match its token.

That creation error looks like a bug. Nothing in the docs lists Service-to-Service OAuth as a known limitation for MCP or AgentCore, the Runtime walkthrough gets past “Create and continue” against AgentCore Runtime with the same three values, and your curl test already rules out the credentials. I’d hold off on putting Cognito or API Gateway in front, since the docs don’t call for it and your token endpoint already works. Open a Support case instead (the MCP integration doc points there for issues it doesn’t cover) and include the timestamp of the failed attempt and your Region.

On hidden parameters, Quick sends an RFC 8707 resource parameter on OAuth requests. It applies default scopes when your protected resource metadata lists none, and it doesn’t support custom HTTP headers (MCP integration doc). Adding resource=<your Gateway MCP URL> to your curl test gets you closer to what Quick actually sends.

The compatibility matrix lists MCP for Flows, but its auth notes only mention Service-to-Service OAuth for Automations and Dashboard Alerts. So do a manual Flow run on the new connector before you schedule it. Meanwhile, your 3LO connector can run scheduled Flows as long as your sign-in is current, and Quick emails you if it expires before a run (scheduling doc).