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

**URL:** <https://community.amazonquick.com/t/mcp-connector-cannot-switch-from-user-oauth-to-service-to-service-oauth-for-scheduled-flows-valid-credentials-rejected-by-quick/54044>\
**Category:** Q&A\
**Tags:** MCP, business-user\
**Created:** [November 3, 2026, 2:36pm UTC](https://community.amazonquick.com/t/mcp-connector-cannot-switch-from-user-oauth-to-service-to-service-oauth-for-scheduled-flows-valid-credentials-rejected-by-quick/54044 "2026-11-03T14:36:31Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![bindaly](https://avatars.discourse-cdn.com/v4/letter/b/9de053/32.png) [@bindaly](https://community.amazonquick.com/u/bindaly)\
**Post date:** [November 3, 2026, 2:36pm UTC](https://community.amazonquick.com/t/mcp-connector-cannot-switch-from-user-oauth-to-service-to-service-oauth-for-scheduled-flows-valid-credentials-rejected-by-quick/54044/1 "2026-11-03T14:36:31Z")

</div>

## 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:

```bash
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!

---

<div class="post-metadata">

**Author:** ![JacobR](https://d2orw1595917va.cloudfront.net/user_avatar/community.amazonquick.com/jacobr/32/37779_2.png) [@JacobR](https://community.amazonquick.com/u/JacobR)\
**Post date:** [November 3, 2026, 3:58pm UTC](https://community.amazonquick.com/t/mcp-connector-cannot-switch-from-user-oauth-to-service-to-service-oauth-for-scheduled-flows-valid-credentials-rejected-by-quick/54044/2 "2026-11-03T15:58:40Z")

</div>

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](https://aws.amazon.com/blogs/machine-learning/integrating-aws-api-mcp-server-with-amazon-quick-suite-using-amazon-bedrock-agentcore-runtime/) sets one up with just a Client ID, secret and Token URL, and the [Gateway walkthrough](https://aws.amazon.com/blogs/machine-learning/connect-an-agentcore-runtime-hosted-mcp-server-to-amazon-quick/) points to Service authentication for more systematic integrations. Once it exists, add the new client ID to your Gateway’s [inbound authorizer](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/inbound-jwt-authorizer.html) 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](https://docs.aws.amazon.com/quick/latest/userguide/mcp-integration.html) 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](https://docs.aws.amazon.com/quick/latest/userguide/mcp-integration.html)). Adding `resource=<your Gateway MCP URL>` to your curl test gets you closer to what Quick actually sends.

The [compatibility matrix](https://docs.aws.amazon.com/quick/latest/userguide/action-connector-apis-supported-types.html) 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](https://docs.aws.amazon.com/quick/latest/userguide/schedules-in-quick-flows.html)).