AWS showed how to connect OAuth-protected MCP servers to Bedrock AgentCore Gateway

AWS showed how to connect OAuth-protected MCP servers to Amazon Bedrock AgentCore Gateway through the Authorization Code flow. The scenario is designed for teams that need single sign-on for AI agents in corporate tools without embedded tokens and without manual setup of each integration.

Why Amazon Bedrock AgentCore Gateway is Needed

AWS positions the Gateway as the central point through which agents and MCP clients get access to tools inside the company. Instead of setting up each MCP server separately in an IDE, the team can give developers one Gateway URL and unified access rules. AWS moves authentication, observability, and access policy control to this layer so that connections to tools don't grow into a set of scattered manual configurations.

This is especially relevant for companies where MCP servers become numerous: their own internal services, GitHub, Salesforce, Databricks, and other external systems. Many such servers are protected by OAuth 2.0 and require that the agent act on behalf of a specific user.

In such a scheme, the Gateway relieves applications of extra work: there is no need to embed credentials in code, independently update tokens, or repeat the same logic for each connector.

Two Connection Modes

In the article, AWS shows two ways to connect an OAuth-protected MCP server to the Gateway. The first is implicit sync when creating a target: the administrator goes through the Authorization Code flow during CreateGatewayTarget, UpdateGatewayTarget, or SynchronizeGatewayTargets, after which the Gateway itself reads the list of tools and caches it. The second is to provide the tool schema in advance without waiting for a live request to the server during target creation. AWS directly names the second option preferred where human involvement in create or update is not possible.

• Implicit sync requires that the admin complete authorization and give the Gateway access to the MCP server already at the setup stage.
• Pre-defined schema allows you to immediately insert the list of tools and get a ready target without authorization when creating.
• In the mode with a schema in advance, you cannot use SynchronizeGatewayTargets, because the Gateway relies on the provided description rather than live reading from the server.
• Gateway users can perform tools/list without logging in to each server, because tool definitions are already in the cache.
• Authorization is triggered only when the user actually calls the needed tool through tools/call.

As an example, AWS uses the GitHub MCP server. For such a scenario, you need a Gateway on MCP version 2025-11-25 or newer, otherwise the Authorization code grant 3LO option will not be available. The configuration also specifies the return URL: this is where the user or administrator returns after the consent screen, and then the application completes the exchange through CompleteResourceTokenAuth.

How Authorization Works

The key part of the scheme is the linking of AgentCore Gateway and AgentCore Identity. First, the Gateway obtains a workload access token, confirming that it is entitled to request credentials on behalf of its workload. Then, through a credential provider, it either receives a ready access token or the authorization URL and session URI if a token has not yet been issued for a particular user. At the initial target setup stage, because of this, it may end up in the Needs authorization status, and after completing the consent move to Ready with an Authorized label.

AWS separately emphasizes URL session binding. The mechanism verifies that authorization was initiated and completed by the same user, not someone who accidentally received a forwarded link. After consent, the browser returns to the callback, the application passes the session URI and user identity to CompleteResourceTokenAuth, and only after this verification does the exchange of authorization code for access token occur. According to AWS, the authorization link and session URI live for 10 minutes, which further narrows the window for abuse.

For the end user, the logic is simpler. The tools/list request is served from the Gateway cache and does not force you to log in to all connected systems in advance. But tools/call already initiates the Authorization Code flow only for that MCP server whose tool is actually being called. After successful login, the token is cached in the Token Vault in the binding of workload identity and user identity, so subsequent calls pass without new authorization as long as the token remains valid.

What This Means

AWS is moving MCP from a set of point integrations into a managed corporate layer. For teams building agent systems on multiple external and internal tools, this reduces access chaos: the tools catalog can be displayed centrally, and user authorization can be activated only at the moment of actual invocation of the needed server.