Benefits of AgentCore Identity OAuth Consent for User Agents

Your agent needs to read a user's GitHub repos and post to their Slack. The OAuth part looks like a one-afternoon job. It becomes a callback server, a session store and a security review. AgentCore Identity OAuth consent is the managed way out, and this article covers what you get from it.

AWS's consent portal for Amazon Bedrock AgentCore Identity is a hosted page. It signs users in to your OpenID Connect (OIDC) identity provider (IdP), then collects their consent before your agent touches a downstream resource on their behalf. It attaches to one AgentCore Gateway. The launch post walks through the console setup.

1. No callback infrastructure to build or host

With the authorization code grant, you used to build the whole return path yourself. That meant presenting the authorization URL, hosting a public HTTPS callback, authenticating the returning user, managing browser sessions and calling CompleteResourceTokenAuth. The portal does all of that. Session binding (proving the person who returns from the provider is the person who started the flow) is handled for you.

Your setup shrinks to one CLI call, once you have an OAuth2 credential provider for your IdP:

aws bedrock-agentcore-control create-consent-portal \
    --name "my-consent-portal" \
    --execution-role-arn "arn:aws:iam::<account-id>:role/<execution-role-name>" \
    --idp-config '{
        "credentialProviderArn": "arn:aws:bedrock-agentcore:<region>:<account-id>:token-vault/default/oauth2credentialprovider/<credential-provider-id>",
        "scopes": ["openid", "email", "profile"],
        "audience": "<audience>"
    }' \
    --sources '[{
        "identifier": "<gateway-id>",
        "type": "agentcore-gateway"
    }]'

The portal starts in CREATING. Poll get-consent-portal until it is ACTIVE to get the portalUrl. Then register <portalUrl>/callback on your IdP with no trailing slash, or the IdP rejects the callback.

2. Users sign in with the IdP they already have

The portal authenticates users against the same OIDC IdP your gateway's inbound JWT authorizer trusts. There is no second login system and no separate user directory.

This also fixes the "whose token is this?" question. The consent is tied to the signed-in user, not to a shared service account.

3. Consent per resource, not one big checkbox

After sign-in, the user sees the gateway's targets and grants access to each provider separately. They can connect GitHub and skip Slack. Each provider's own OAuth screen shows its scopes, so the user approves what that provider actually asks for.

That is better for least privilege than a blanket grant.

4. Tokens stay server-side, in the vault

The portal keeps the OAuth flow server-side, so the browser never holds a token. Per-user tokens land in the AgentCore Identity token vault, and the service refreshes them when the provider allows it. If it can't, the user re-authorizes.

5. A built-in audit trail

Consent operations are recorded in AWS CloudTrail. The launch post names three events: GetResourceOauth2Token when the portal starts OAuth, CompleteResourceTokenAuth when session binding finishes, and GetWorkloadAccessTokenForJWT when the portal gets gateway access. When someone asks "who authorized this agent to read that repo, and when?", you can answer from logs you didn't have to write.

6. Works for IDE and MCP clients

The launch post calls out IDE and Model Context Protocol (MCP) clients such as Kiro, Claude Code, Cursor and Visual Studio Code. Those clients have no web app of yours to host a redirect, so a hosted URL you hand to users fits.

When it's not worth it

Skip the portal if any of these describe you:

• Your agent is not behind an AgentCore Gateway. A portal attaches to exactly one gateway.
• You need a custom consent UI or branding. The page is AWS-hosted.
• Your IdP is not OIDC, or the flow is not an authorization code grant (for example, machine-to-machine client credentials).
• You have one internal user and one token. A hand-rolled flow may be less setup than a portal, an execution role and three registered callback URLs.

Gotchas

• Include openid in idpConfig.scopes; the portal requests it regardless, and every scope must be permitted on the IdP or you get invalid_scope.
• A trailing slash on the callback URL breaks sign-in.
• A gateway with no targets shows an empty portal page. Add targets first.

If your agents act for individual users in production, the consent portal moves the riskiest part of OAuth, the token handling, off your plate and into a service with an audit trail.