Last updated: September 2026
Amazon Bedrock AgentCore Identity’s managed consent portal, announced by AWS in September 2026, removes the callback infrastructure teams had to build so that agents could complete OAuth 2.0 three-legged flows against tools like GitHub, Salesforce and Slack. It is not an alternative to Keycloak for signing users in: the portal requires an OIDC identity provider of your own as the primary IdP, and Keycloak is a perfectly good one. The real comparison is narrower, and it is about outbound grants: whether the third-party tokens your agents use live in AgentCore’s per-gateway vault or in your identity provider’s broker store.
Both sides do standard OAuth, so the question is not protocol quality. It is where the record of “this user let this agent touch their GitHub” lives, and what moving it costs later.
Key takeaways
- The portal removes hosted callback and session-binding code, which is genuine undifferentiated work.
- It sits on top of your existing OIDC provider, which must issue JWT access tokens, rather than replacing it.
- What it owns is the outbound leg: per-gateway credential providers and the token vault holding third-party grants.
- Keycloak covers that same outbound leg with identity brokering, and hosts the third-party callback itself.
What does the AgentCore Identity consent portal actually solve?
It solves hosted callback infrastructure. Before it, teams using AgentCore Gateway to connect agents to third-party services had to build, host and maintain their own OAuth callback endpoints to complete 3LO flows, plus the session binding that ties a returning consent redirect back to the agent session that started it. AWS describes the portal as removing exactly that undifferentiated heavy lifting for agent developers and platform administrators.
The shape is specific. Each AgentCore Gateway receives its own managed consent portal with a dedicated hosted web client and a credential provider list. A platform administrator can share that portal URL with a team ahead of any agent session, so consent is granted before the agent needs it rather than in the middle of a tool call. End users get a self-service view of their connection status without filing a ticket.
What it does not do is sign your users in. AWS’s prerequisites are explicit that a consent portal needs an OAuth2 credential provider pointing at your own JWT-issuing OIDC identity provider, the one end users actually authenticate to, referencing the same issuer as the gateway’s JWT authorizer. Providers that issue opaque access tokens are not supported in that role. So the inbound hop stays with Okta, Entra, Keycloak or whatever you already run, and the portal handles the outbound hop to GitHub or Slack and stores the resulting tokens in the AgentCore token vault.
The pre-session consent detail is the interesting one, and it is a response to a real constraint rather than a convenience feature. Agent clients embedded in an IDE often cannot present an OAuth consent URL to a human or handle the redirect that comes back. AWS calls out those clients explicitly as the target. Moving consent out of band, to a URL a person opens in a normal browser at a normal time, is the practical answer when the agent’s own surface cannot host that second redirect.
Where does the AWS coupling show up?
It shows up in the binding between agent runtime and outbound grants. The portal is per AgentCore Gateway, the credential providers are AgentCore resources, and the tokens land in a vault whose lifecycle belongs to the AI platform rather than to your identity platform.
That is fine, and in some architectures it is correct, until one of three things happens. You run agents somewhere other than Bedrock and need the same tool connections. You need the record of who consented to what to live in the same audit and access-review process as every other grant in the company. Or you need to revoke an agent’s access to a third-party tool as part of an offboarding workflow that never learned about AgentCore.
Every managed identity feature trades assembly for coupling, which is a reasonable trade when the coupled thing is stable. Agent runtimes in 2026 are not the stable layer. The same team frequently runs Bedrock agents, an MCP server or two and something in a developer’s IDE, and each of those wants the same GitHub connection.
How does Keycloak handle OAuth for AI agents?
It uses four pieces that already exist, none of them agent-specific. This is the part worth being concrete about, because “you can build it on Keycloak” is not an answer.
Confidential clients and service accounts. Each agent gets a client identity with its own secret or private key JWT, so tokens trace back to a named principal and can be disabled individually. Service accounts cover the machine-to-machine calls an agent makes on its own behalf, as distinct from calls it makes for a user. The patterns are set out in agent authentication with Keycloak.
Authorization code with PKCE, plus per-client consent. Keycloak’s client-level consent setting gives you the consent screen and the record of what was granted, and the account console gives users a self-service view of their applications. For the outbound leg, the leg AWS’s portal completes, Keycloak is already the callback: the broker endpoint at /realms/{realm}/broker/{alias}/endpoint is hosted by Keycloak, not by you.
Identity brokering for the third-party tokens. This is the closest analogue to the credential provider list plus token vault, and the part most people miss. With Store tokens enabled on the provider, Keycloak hands that provider’s token back to an authorized client:
curl -H "Authorization: Bearer $KEYCLOAK_ACCESS_TOKEN"
"https://id.example.com/realms/agents/broker/github/token"Your agent asks Keycloak for the user’s GitHub token rather than holding one itself. Mind which API you build against: this V1 endpoint gates on the broker client’s read-token role and is marked deprecated in the Keycloak docs, slated for removal in a future version. The V2 API, behind the identity-brokering-api:v2 feature flag, moves to POST, restricts retrieval to confidential clients, and replaces the user role with two client settings, “Allow retrieve external tokens” and an allowed-provider list. For an agent, which is a confidential client rather than a person, V2 is the better fit. The claim mapping side is covered in attribute mapping during OIDC identity brokering.
Token exchange for audience narrowing. An agent acting for a user needs a token scoped to one downstream resource rather than a standing key, which is what standard token exchange does. Be aware of its edges: it is aimed at narrowing an internally issued token, and the delegation and brokering cases are where the feature is still moving. The token exchange guide covers the mechanics, and cross-app access with ID-JAG covers where the standards are heading for agent delegation specifically.
The gap is narrower than the marketing on either side suggests. Keycloak already hosts the callback, and the account console’s Linked Accounts page already lets a user connect GitHub ahead of any agent session and, with Store tokens on, keeps the token. What Keycloak does not give you is the per-gateway framing: one URL scoped to a set of agents, and a status view that maps tool targets to providers rather than listing a realm’s identity providers. That is the page you would write, and it is a small one.
What do you still own either way?
You own discovery, scope discipline and revocation practice. Neither product solves these, and they cause more incidents than the consent flow does.
Shadow agents are the first. Any developer with an API key can wire an agent to a tool without going through a gateway or an IdP, and neither AgentCore nor Keycloak can see what never asked them. The control is network egress and credential issuance policy, not identity configuration.
Scope creep is the second. Agents ask for broad scopes because broad scopes make demos work, and the consent screen a user clicks through in two seconds is where that becomes permanent. Reviewing what agent clients actually request, and refusing the convenient wildcard, is an ongoing job that belongs to whoever owns the client registry.
Revocation that actually revokes is the third. Short-lived access tokens with refresh rotation give you a real kill switch; a stored long-lived third-party token does not, wherever it is kept. If an agent’s GitHub token lives in the AgentCore vault or in a Keycloak broker store, disabling the agent’s client does not invalidate that upstream token, so you have to revoke it at GitHub as well, which is a step both architectures make easy to forget.
When is AgentCore enough, and when do you want a portable IdP?
AgentCore is enough when the agent fleet is Bedrock-only, the tool connections are ones you can express as an OAuth2 credential provider (AWS ships presets for the common SaaS targets alongside a custom provider config), and the grant record does not need to join your existing access reviews. In that case you are buying a page you would otherwise write, inside a platform you have already committed to, and the coupling costs nothing you will feel.
A portable IdP earns its keep in three situations. Multi-cloud or multi-runtime agent fleets, where the same GitHub connection has to serve agents in more than one place. Regulated environments where agent grants have to sit in the same audit trail as human access, reviewed on the same cycle. And any architecture where the agents are a feature of your product rather than an internal tool, because then the consent screen is your product’s surface and carries your brand.
There is a fourth case, quieter than the others: teams that expect to change AI platforms at some point. Identity is the layer you least want to migrate at the same time as a runtime, which is the argument running through agentic IAM heading into 2026 and through Auth0’s agentic commerce push versus an MCP-native Keycloak setup.
If the agents will talk to MCP servers, that decision arrives sooner than you expect, because MCP server authorization wants an authorization server independent of any one runtime by design.
What does running Keycloak for this actually cost you?
It costs operational time, which is the reason people reach for a managed option in the first place. Upstream Keycloak gives you every primitive above with no license fee, and it gives you upgrades, high availability, database operations and security patching to run yourself. The honest accounting is in is self-hosting Keycloak worth it in 2026.
Skycloak runs upstream Keycloak unforked as identity management as a service, so the primitives above are the stock ones and the configuration exports as plain OIDC. The comparison here is not managed against unmanaged. It is which layer you want managed, the AI runtime or the identity layer.
Frequently asked questions
What is the Amazon Bedrock AgentCore Identity consent portal?
A managed hosted page, announced by AWS in September 2026, that completes OAuth 2.0 three-legged authorization flows for agents connecting to third-party tools. Each AgentCore Gateway gets its own portal URL and credential provider list. It authenticates users against your own OIDC provider and handles the outbound grant, rather than replacing your identity provider.
Can Keycloak do agent OAuth consent without AWS?
Yes, using standard pieces: confidential clients for agent identity, authorization code flow with PKCE, per-client consent settings for the grant record, and identity brokering to hold and hand back third-party provider tokens. Keycloak hosts the third-party callback itself. What you would add is a per-gateway status page mapping tool targets to providers.
Does AgentCore Identity lock you into AWS?
Not for user sign-in, since the portal runs on top of whatever OIDC provider you already have. It does couple the outbound grants: portals are per gateway, credential providers are AgentCore resources, and the third-party tokens sit in that service’s vault. For agents running in more than one place, the same tool connection has to be established twice.
How do you revoke an agent’s access to a third-party tool?
Disable the agent’s client at your identity provider to stop new tokens, then revoke the stored upstream token at the third-party service itself. The second step applies to both architectures: a token held in the AgentCore vault or a Keycloak broker store stays valid at the provider until it is revoked there.
Which is better for MCP servers specifically?
An authorization server independent of the agent runtime, because MCP servers are typically reached by several kinds of client: hosted agents, IDE integrations and CI jobs. Tying the authorization model to one AI platform means the other clients need a second path to the same tools.
Sources
- AWS, “Amazon Bedrock AgentCore Identity now offers a managed consent portal”, AWS What’s New, September 2026, retrieved 2026-09-21
- AWS Machine Learning Blog, “Manage end-user OAuth consent for AI agents with Amazon Bedrock AgentCore”, 2026, retrieved 2026-09-21
- AWS, “Configure a consent portal target”, Amazon Bedrock AgentCore Developer Guide, 2026, retrieved 2026-09-21