Amazon Web Services has added a managed Consent portal and session binding endpoint to Amazon Bedrock AgentCore Identity, letting AgentCore Gateway users authorize an AI agent to access services such as GitHub or Slack without customers building the browser and callback infrastructure themselves. Developers using an IDE or Model Context Protocol client can grant provider-specific access in the portal, then return to their client and use the resulting token through the same gateway.
The change applies to three-legged OAuth, also known as the OAuth 2.0 authorization code flow. AWS says customers previously had to present the provider’s authorization URL, operate a public HTTPS callback, authenticate the returning user, manage the browser session and invoke CompleteResourceTokenAuth to associate the grant with the correct user.
The managed portal takes over those redirects and the session-binding step. Users sign in through their organization’s identity provider, inspect the connections exposed by the attached gateway and approve providers individually. AgentCore Identity stores the resulting per-user tokens in its token vault, allowing later tool calls to reuse a valid grant.
What administrators still configure
The portal reduces custom OAuth infrastructure but does not eliminate the surrounding identity setup. AWS’s walkthrough requires an AgentCore Gateway configured for JWT inbound authorization, an IDE or MCP client connected to that gateway, administrative access to a corporate identity provider, and registered OAuth applications for the outbound services. The example uses separate GitHub and Slack applications and credential providers.
For portal sign-in, an administrator creates an OpenID Connect web application at the corporate identity provider, enables the authorization code grant and configures at least the openid scope. The identity provider must return a JWT access token that the portal can validate; AWS notes that some providers may need authorization-server, access-policy or audience configuration to avoid returning an opaque token.
The corporate identity provider’s client ID, client secret and OIDC discovery configuration are registered in an AgentCore Identity OAuth2 credential provider. Separately, each outbound service needs its own OAuth credential provider and gateway target. In the documented GitHub and Slack example, the applications’ secrets reside in AWS Secrets Manager, their AgentCore Identity callback URLs must be registered with the matching services, and the targets must use the authorization code grant and reach Ready status. The portal’s execution role also needs access to any customer-managed secrets those providers reference.
Administrators create the portal for a specific gateway in the AgentCore Identity console and select its identity-provider credential configuration and IAM execution role. Only one Consent portal is allowed for each gateway, and the selected gateway cannot be changed after the portal is created. The gateway name is displayed to users, making its naming part of the consent experience. Portal names accept 1–50 letters, numbers, hyphens or underscores, while descriptions can contain up to 512 characters.
Once provisioning changes the portal status from Creating to Active, AWS assigns a URL following https://<gateway-name>.consent-portal.bedrock-agentcore.<region>.amazonaws.com. The administrator then distributes that URL after completing three distinct callback mappings:
<portal-url>/callbackbelongs in the corporate identity-provider application and returns the user after portal login.<portal-url>/connect/callbackis the gateway target’s default return URL and sends the browser to the managed session-binding endpoint.- The unique AgentCore Identity
callbackUrlbelongs in the relevant outbound provider application and receives that provider’s authorization code.
These addresses are not interchangeable. In particular, the corporate sign-in callback is separate from the callback registered with GitHub or Slack. AWS also advises requesting only the scopes each target requires and scoping iam:PassRole to the chosen execution-role ARN when an administrator supplies a role rather than using the console-created default.
Consent remains specific to each user and provider
After opening the shared portal URL, a developer signs in through the corporate identity provider. The portal uses its IAM execution role to retrieve the gateway’s configured targets and current connection state. The developer can then select GitHub, review the scopes on GitHub’s own consent screen and approve access.
Returning to the portal completes session binding and changes GitHub to Connected. Slack can remain Not connected until it is actually needed, demonstrating that one provider’s approval does not implicitly authorize another. If Slack access is later required, the user separately chooses a workspace, reviews the requested permissions and approves that application. The developer can then return to the IDE or MCP client attached to the same gateway and retry the relevant tool call.
That independent-grant model matters for agents with several external tools: the user can authorize only the service needed for a task and can disconnect a provider without removing the others. Connected providers remain visible on later visits to the portal, and a user can reconnect after disconnecting.
How the binding flow works
Behind the interface, the portal validates the identity-provider response and establishes an encrypted browser session. It lists the gateway’s 3LO targets through its execution role. When the user chooses Connect, the portal calls GetResourceOauth2Token, which returns an authorization URL and session URI.
The outbound provider sends its authorization code to AgentCore Identity, after which the browser reaches the portal’s managed binding endpoint. The portal invokes CompleteResourceTokenAuth with the authenticated user context, associating the provider grant with the user who approved it.
If the provider returns a refresh token, AgentCore Identity stores it and can obtain a new access token when the current one expires. That continuity is conditional: a provider might not issue a usable refresh token, or the token may expire or be revoked. When no valid refresh token remains and the access token can no longer be used, the user must revisit the portal and authorize the provider again. AWS recommends enabling refresh-token behavior where supported, citing user-to-server token expiration for GitHub and token rotation for Slack.
CloudTrail records the consent path
AgentCore records the relevant operations in AWS CloudTrail under the event source bedrock-agentcore.amazonaws.com. Administrators can inspect GetResourceOauth2Token when authorization begins, CompleteResourceTokenAuth when session binding finishes and GetWorkloadAccessTokenForJWT when the portal obtains gateway access for the authenticated user.
A GetResourceOauth2Token event can identify the credential provider, requested scopes, OAuth flow, portal execution role and AWS Region. AWS says sensitive token and state fields are redacted. For failed flows, the documented troubleshooting path is to correlate errorCode and errorMessage with the event time, assumed role, Region, provider and requested scopes.
Cleanup has an ordering constraint: a gateway target must be deleted before its outbound OAuth credential provider, because a provider still referenced by a target cannot be removed. Administrators should also remove portal callbacks from the corporate identity provider and gateway targets, then delete unused credential providers and the portal execution role.
Source: AWS Machine Learning Blog
Definition. The AgentCore Consent portal is a managed interface that handles three-legged OAuth redirects, user consent and provider-grant binding for a specific AgentCore Gateway.
| Callback address | Purpose |
|---|---|
| /callback | Returns the user from the corporate identity provider after portal sign-in. |
| /connect/callback | Sends the browser from the gateway target to the managed session-binding endpoint. |
| AgentCore Identity callbackUrl | Receives the authorization code from the relevant outbound provider application. |
Key takeaways
- The portal manages browser redirects and session binding for OAuth 2.0 authorization code flows.
- Each user approves providers independently, so connecting one service does not authorize another.
- AgentCore Identity stores per-user tokens and can refresh access when a usable refresh token is available.
- Administrators still need corporate identity-provider configuration, outbound OAuth applications, gateway targets and an IAM execution role.
- Each gateway supports one Consent portal, and its selected gateway cannot be changed after creation.
- CloudTrail records authorization, session-binding and gateway-access operations for auditing and troubleshooting.
FAQ
What does the AgentCore Consent portal replace?
It replaces customer-hosted browser redirects, public HTTPS callbacks and custom session-binding infrastructure used to associate an outbound provider grant with the correct user.
Does approving GitHub also authorize Slack?
No. Consent is specific to each user and provider, so GitHub and Slack must be connected and approved separately.
What must administrators still configure?
They must configure JWT inbound authorization, a corporate identity provider, outbound OAuth applications and credential providers, gateway targets, callback mappings and an IAM execution role.
Can one gateway have multiple Consent portals?
No. Only one Consent portal is allowed per gateway, and the selected gateway cannot be changed after portal creation.
What happens when an access token expires?
AgentCore Identity can obtain a new access token if the provider supplied a usable refresh token. Otherwise, the user must return to the portal and authorize the provider again.
How can administrators audit the consent flow?
AWS CloudTrail records operations including GetResourceOauth2Token, CompleteResourceTokenAuth and GetWorkloadAccessTokenForJWT under bedrock-agentcore.amazonaws.com.
