Choosing to Propagate Gateway Inbound Token to Target (MCP Server) as option (On-Behalf-Of - OBO)

### Summary
Allow Amazon Bedrock Gateway to **optionally forward the inbound OAuth user token** if available, to a specific **target**, using for example On-Behalf-Of (OBO) or aws_client_metadata pattern.

Is this possible ?

I’m building a multi-organization Bedrock Gateway using Amazon Bedrock AgentCore. The Gateway uses a custom OAuth2 provider for authentication, and each inbound user JWT contains user- and organization-level claims.

When the Gateway invokes a given downstream (MCP in my case) target, it currently exchanges credentials using the configured Identity OAUTH credential provider which are static. This works, but the target receives a new access token, generated via the Identity outbound auth client_credentials flow, which no longer carries the original user (On-Behalf-Of - OBO) identity from the inbound token. For this I wish to pass On-Behalf-Of the current gateway user.

This would allow the Gateway to continue obtaining tokens securely via client credentials, but still carry forward the original user/organization identity as a context to the target if choosen.

Client (Bearer user_token)
↓
Gateway authenticates user_token
↓
Gateway User selects and calls a target (forwards inbound token (onBehalfOfToken) because this target allows it.)
↓
Target MCP server receives token and executes on behalf of that user (letting certain targets retain user and organization identity for access control or audit purposes.)

```
client.create_gateway_target(
gatewayIdentifier=gateway_id,
name="MyTarget",
targetConfiguration={"mcp": {"mcpServer": {"endpoint": mcp_url}}},
credentialProviderConfigurations=[{
"credentialProviderType": "OAUTH",
"credentialProvider": {
"oauthCredentialProvider": {
"providerArn": my_oauth_provider_arn,
"forwardInboundToken": True, # Example New flag
}
}
}]
)
```

**What I found:**
https://docs.aws.amazon.com/cognito/latest/developerguide/token-endpoint.html#exchanging-client-credentials-for-an-access-token-in-request-body

> Cognito then makes that metadata available in the pre token generation trigger, where custom logic can enrich the new token with claims derived from onBehalfOfToken.
> "aws_client_metadata
> Optional.
> Information that you want to pass to the [Pre token generation Lambda trigger](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html) in [machine-to-machine (M2M)](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-define-resource-servers.html) authorization flows. Your application can collect context information about the session and pass it in this parameter. When you pass aws_client_metadata in URL-encoded JSON format, Amazon Cognito includes it in the input event to your trigger Lambda function. Your pre token trigger event version or global Lambda trigger version must be configured for version three or later. Although Amazon Cognito accepts requests to this endpoint in authorization code and client credentials M2M flows, your user pool only passes aws_client_metadata to the pre token generation trigger from client credentials requests."

Start with the client.create_gateway_target entry point and the proposed credentialProviderConfigurations example, then read the linked Amazon Cognito token-exchange documentation. Done means determining whether per-target forwarding of the inbound token or OBO context is supported and defining the required behavior and configuration.

Written by the indexing model from the issue text.