Agentic Commerce Authentication: Tokens vs Payment Mandates

Last updated: September 2026

An AI shopping agent needs two separate pieces of proof, and the most common design mistake is trying to make one of them do both jobs. The access token answers “may this agent call this merchant’s API as this user,” and it should be audience-restricted, short-lived and revocable. The signed mandate answers “what exactly did the human authorize,” carrying the item, the price ceiling and the expiry. Both of the open commerce specs, the Agentic Commerce Protocol from OpenAI and Stripe and Google’s Agent Payments Protocol, put the commercial limits in the mandate rather than in the token. Teams that encode spending limits into OAuth scopes instead end up with a permission model they cannot change at purchase time. Auth0 sells this as a managed layer; Keycloak gives you the primitives to run it yourself, with one gap around resource indicators worth knowing before you design around it.

If you’re a platform team at a retailer or a B2B marketplace, the protocol layer above you is still moving. The identity decisions below it are the ones that outlive whichever checkout spec wins.

What does agentic commerce actually change about identity?

It adds a party. Classic ecommerce identity has a user and a merchant, and the token in between says who the user is. Agentic commerce inserts a third participant that holds a token, acts asynchronously, and may be operated by a company that is not you and not the shopper. The token now has to say who the user is, which agent is acting, what that agent may do, and for how long.

Three properties follow from that, and they show up in every serious design:

• Delegation is explicit and bounded. The agent gets authority for a task, not a session. “Buy this item under this price before Friday” is a different grant from “act as this user.”
• The grant is short-lived and revocable. An agent token that outlives the errand is a standing credential, which is the thing everyone says they want to avoid.
• Audience matters. A token minted for one merchant’s tools should be useless at another’s, which is the whole point of resource-scoped tokens.

How do you scope an agent’s token so it can only buy what it was asked to buy?

Scope the token to one merchant resource and one narrow permission set, mint it for minutes rather than hours, and keep the spending limit in the payment mandate rather than in the access token. This is the part teams most often get wrong, usually by trying to encode purchase limits into scopes.

The cleaner separation looks like this:

1. The access token answers “may this agent call this tool as this user.” Audience-restricted to the merchant’s resource, short-lived, revocable, and carrying the user subject plus the agent’s client identity.
2. The mandate answers “what did the human actually authorize.” Item, price ceiling, expiry, signed at authorization time. Both ACP’s delegated payment spec and AP2’s cart and payment mandates put the commercial limits here, and both describe single-use credentials with allowances rather than reusable ones.
3. The merchant enforces both. A valid token with no matching mandate is a request the merchant should refuse, and this is worth writing as an explicit check rather than assuming the token implies consent.

The mistake we keep seeing: treating scopes as a spending limit. Scopes are coarse, they’re cached, and they’re granted at consent time rather than at purchase time, so a scope named something like purchase:under_100 ages badly the moment a user wants to buy something for 120. Keep money limits in the signed mandate, where they belong, and let the token carry identity and audience only.

The two open specs express the mandate differently and agree on the principle. AP2, Google’s Agent Payments Protocol announced in September 2025, structures authorization as three signed mandates covering intent, cart and payment, expressed as W3C Verifiable Credentials. ACP, co-developed by OpenAI and Stripe and published under Apache 2.0 in September 2025, uses a delegated payment token that is single-use and carries allowances, with Stripe’s Shared Payment Token implementing the spec. Worth noting on dates: ACP’s own changelog puts the delegated authentication component, along with cart, feed, orders and MCP support, in the April 2026 release rather than the original one, and the repository still marks the specification as Beta.

What can Keycloak actually issue today?

The OAuth building blocks are there, with one gap. Keycloak documents its role as an MCP authorization server, supports the authorization code flow with PKCE and client credentials for machine identities, and standard token exchange compliant with RFC 8693 became officially supported in 26.2, covering internal-internal exchange within a realm.

The gap is resource indicators. RFC 8707 lets a client request a token scoped to a named resource by sending resource=https://merchant.example/tools, and it’s how the MCP authorization spec expects audience restriction to work. Initial native support has merged as an experimental feature, RESOURCE_INDICATORS("Resource Indicators for OAuth 2.0", Type.EXPERIMENTAL) in Profile.java at the 26.6.0, 26.7.0 and 26.7.3 tags, while upstream’s own MCP guide still lists RFC 8707 as not supported. The tracking issue, keycloak/keycloak#14355, is open against the 26.8 milestone, so this is a status likely to change within a release or two.

For production today that means the audience protocol mapper, which stamps the audience you want onto tokens issued to a given client. We documented the failure mode it prevents in fixing the MCP 401 audience claim, the registration side in the CIMD walkthrough, and the general agent patterns in authenticating AI agents with Keycloak.

What is Auth0 selling, and what does it replace?

Auth0 announced AI Identity for Agentic Commerce in September 2026, aimed at authenticating shoppers and agents inside AI-assisted checkout, alongside its Auth for MCP work and dedicated machine-to-machine identities for agents. The pitch is that the delegation plumbing arrives as a product rather than as a design exercise, which is a real advantage when you have a deadline. The agent identity problem has a lot of fiddly parts and a vendor that already made the decisions saves you a quarter of arguing about them.

Two things belong next to that. On availability, Auth0’s own site still describes the agentic commerce and Agent as Principal launches as upcoming as of mid-September 2026, so confirm the current stage against its release materials rather than a press cycle before planning a launch around it. On lock-in, the layer being sold is the one most likely to be commoditized, because ACP and AP2 are both open specifications with broad backing. Binding your delegation model tightly to one vendor’s implementation of a spec that is still converging is a cost that shows up later rather than now. We laid out the general shape of that tradeoff in the Auth0 and Keycloak comparison.

What about multi-tenant merchants and per-merchant isolation?

Use Keycloak Organizations when merchants need their own users, identity providers and administrative boundary inside one realm, rather than spinning up a realm per merchant. This is the tenancy question B2B SaaS teams already answer, and agentic commerce raises the stakes rather than changing the shape, because an agent token that leaks across a tenant boundary is a purchase made in someone else’s name.

The per-merchant checklist is short: distinct audience values per merchant resource, mandates verified against the merchant that will fulfill them, and audit events retained long enough to reconstruct a disputed transaction. We compared the managed alternative in Auth0 B2B Connect versus Keycloak Organizations, and the cross-application case where one agent moves between services is covered in cross-app access and ID-JAG for AI agents.

Which path should a retail or marketplace team pick?

Pick the managed layer if agent commerce is a feature you’re adding to a product whose identity already lives with that vendor, and you want it live this quarter. Pick the open authorization server if identity is infrastructure you intend to keep, or if the same system already issues tokens for your existing customer logins and you would rather not run two.

For a retail team that has never operated an identity provider, the category worth comparing against a managed product is identity management as a service, meaning the same open authorization server with someone else running it. Skycloak runs upstream Keycloak, so the token exchange configuration, the audience mapper and the experimental flags behave exactly as described here, and what changes is who tracks resource-indicators from experimental to supported.

The hybrid is common and is not a compromise. Keeping an existing IdP for customer sign-in while standing up Keycloak as the authorization server for agent and MCP traffic gives you one place to reason about delegation without a migration project attached. Whichever way it goes, two decisions are worth making deliberately now because they are expensive to revisit: where the spending limit is expressed, and whether your tokens are audience-restricted per merchant. Much of the rest of this stack is likely to be rewritten by the protocol working groups within a year.

The wider vendor picture, including where Okta, Ping and JumpCloud have landed on agent identity, is in Agentic IAM in 2026. If you’re protecting MCP tools rather than calling them, start with securing MCP servers using Keycloak.

Frequently asked questions

How do you build secure agentic commerce?

Separate identity from authorization limits. Issue short-lived, audience-restricted OAuth tokens that prove which agent acts for which user, and carry the purchase constraints in a separately signed mandate, as both the Agentic Commerce Protocol and Google’s Agent Payments Protocol do. The merchant verifies both before fulfilling, rather than treating a valid token as consent.

What is the Agentic Commerce Protocol?

ACP is an open specification for agent-initiated checkout, co-developed by OpenAI and Stripe and published under Apache 2.0 in September 2025, with the repository marking it Beta. It covers agentic checkout sessions, product feeds, orders, delegated payment tokens and delegated authentication, though the authentication and MCP components arrived in the April 2026 release rather than the original one.

How is AP2 different from ACP?

AP2, Google’s Agent Payments Protocol announced in September 2025, structures authorization as three signed mandates covering intent, cart and payment, expressed as W3C Verifiable Credentials. ACP structures checkout as protocol endpoints with a single-use delegated payment token. Google’s Universal Commerce Protocol, launched with Shopify in January 2026, is compatible with AP2 through a mandates extension on checkout.

Does Keycloak support RFC 8707 resource indicators?

Not as a default-on feature. Initial support has merged behind an experimental flag, resource-indicators, declared in Profile.java at the 26.6.0, 26.7.0 and 26.7.3 tags, and the tracking issue is open against the 26.8 milestone. Upstream’s MCP guide still lists RFC 8707 as not supported, so production deployments restrict audience using an audience protocol mapper instead.

Can one Keycloak realm serve both human shoppers and AI agents?

Yes, and it is usually the right shape. Human logins use the authorization code flow with PKCE, agents use service-account clients or token exchange, and the two share one user store, one audit log and one set of policies. Keep audiences distinct per resource so an agent token is never accepted where a user token is expected.

Do I need a vendor product for agent identity?

No. The primitives are standard OAuth: PKCE, client credentials, token exchange under RFC 8693, and audience restriction. A managed product buys you time and opinionated defaults, which has real value on a deadline. It does not buy a capability that is otherwise unavailable, since the protocols underneath are open specifications by design.

Sources

• Agentic Commerce Protocol, specification repository maintained by OpenAI and Stripe, status Beta, changelog for the April 2026 release, retrieved 2026-09-15, https://github.com/agentic-commerce-protocol/agentic-commerce-protocol
• OpenAI Developers, “Delegated Payment Spec, Agentic Commerce,” retrieved 2026-09-15, https://developers.openai.com/commerce/specs/payment
• Stripe, “Developing an open standard for agentic commerce,” retrieved 2026-09-15, https://stripe.com/blog/developing-an-open-standard-for-agentic-commerce
• Google Developers Blog, “Under the Hood: Universal Commerce Protocol (UCP),” retrieved 2026-09-15, https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/
• Okta Newsroom, “Okta launches new identity innovations to unlock business growth in the agentic era,” September 2026, retrieved 2026-09-15, https://www.okta.com/newsroom/press-releases/auth0-launches-new-identity-innovations/
• Keycloak, “Standard Token Exchange is now officially supported in Keycloak 26.2,” May 2025, retrieved 2026-09-15, https://www.keycloak.org/2025/05/standard-token-exchange-kc-26-2
• Keycloak, “Integrating with Model Context Protocol (MCP),” retrieved 2026-09-15, https://www.keycloak.org/securing-apps/mcp-authz-server
• Keycloak, Profile.java at tag 26.7.3, RESOURCE_INDICATORS and CIMD experimental feature declarations, retrieved 2026-09-15, https://github.com/keycloak/keycloak/blob/26.7.3/common/src/main/java/org/keycloak/common/Profile.java
• Keycloak, issue #14355, “Support for RFC 8707 OAuth2 Resource Indicators,” open against milestone 26.8, retrieved 2026-09-15, https://github.com/keycloak/keycloak/issues/14355
• IETF, “RFC 8707, Resource Indicators for OAuth 2.0,” retrieved 2026-09-15, https://www.rfc-editor.org/rfc/rfc8707