I’ve setup an MCP action to my CloudAuth protected service behind MCP gateway. The endpoint is protected with federate and the QuickSuite agent is able to authenticate and hit the endpoint. However it does not provide a transitive auth (TA) token. This makes it impossible to manage user level permissions for specific operations within the MCP service. The TA token provided includes ”Unknown Client” when it should be the user’s alias.
Hi @shattij,
Welcome to the Quick Community! I think this may be a current limitation in Quick in regard to how it handles authentication context. However, I would definitely recommend creating a support ticket with AWS Support, as they may be able to further guide you on a workaround for this issue.
Thank you!
Hi @shattij
It’s been a while since we last heard from you. If you have any further questions, please let us know how we can assist you.
If we don’t hear back within the next 3 business days, we’ll proceed with close/archive this topic.
Thank you!
I reached out to AWS support and got this response:
Thank you for the detailed investigation and the decoded TA tokens - that made it much easier to identify the root cause.
You’ve discovered a known limitation with QuickSuite’s current authentication implementation. According to the official QuickSuite and AgentCore documentation (https://w.amazon.com/bin/view/AmazonFederate/help/QuickSuiteAndAgentCore/):
QuickSuite does not currently support OBO (On-Behalf-Of) delegation semantics in its user authentication flow to MCP servers. This is why you’re seeing “UnknownClient” instead of your user alias in the TA token.
Good news on timeline: According to the A5 Roadmap (https://w.amazon.com/bin/view/AmazonInternalAuth/A5/Roadmap/), the A5 team has this work scheduled:
MCPGateway Integration (Item #2): Provide OBO tokens to remote MCP servers built via MCPGateway
Expected Completion Date: May 22, 2026
This feature will enable MCP servers to receive proper user identity in TA tokens without requiring builder effort.
Why Kiro CLI works but QuickSuite doesn’t:
Kiro CLI runs in your Midway session with direct access to your user credentials, so it can initialize TAtokens with your actual identity
QuickSuite authenticates as a service using Federate OAuth, not as the end user, and currently lacks the OBO delegation mechanism to propagate your identity downstream
Workaround options until OBO is available (May 2026):
Service-level authorization: Implement authorization at the service level instead of user-level, granting permissions to the MCPGatewayService principal. This is the most straightforward approach if your use case allows it.
Wait for OBO support: Given the May 2026 timeline is only ~3 months away, you might choose to wait for the official solution if user-level permissions aren’t immediately critical.