UCP Identity Linking Overview
> UCP identity linking is the capability that allows an AI agent to authenticate a buyer's existing merchant account during a UCP interaction — using OAuth 2.0 Authorization Code flow combined with JWT intent assertions — enabling personalised commerce experiences like stored addresses, loyalty rewards, and account-linked checkout without exposing buyer credentials to the agent.
---
What Is UCP Identity Linking?
UCP identity linking is the protocol mechanism that connects a buyer's AI agent session with their existing account at a UCP-enabled merchant. Without identity linking, every UCP interaction is a guest session — the agent can search products, build a cart, and complete checkout, but the transaction has no connection to the buyer's merchant account. With identity linking, the agent can establish an authenticated session that gives the buyer access to their stored delivery addresses, order history, loyalty points, and account-specific pricing.
Identity linking is an optional UCP capability. Google's UCP implementation guide explicitly states that guest checkout is the default path and requires no extra implementation steps. Merchants who want to support account-linked checkout — with all the personalisation and loyalty benefits that entails — must implement the identity linking capability as an additional step beyond the core UCP setup.
The design principle of UCP identity linking is that the buyer's credentials are never exposed to the AI agent. The agent acts as a facilitator — initiating the linking flow and relaying tokens — but the actual authentication happens between the buyer and the merchant's own identity system via standard OAuth 2.0. The agent never sees the buyer's password, and the merchant never receives the buyer's credentials in plain text via the agent.
---
How Identity Linking Works
UCP identity linking uses OAuth 2.0 Authorization Code flow (RFC 6749) as its foundation, with JWT (JSON Web Token) assertions used by Google to combine intent checks and token exchanges into a single efficient flow. The implementation involves three intent types: `check`, `create`, and `get`.
`check` intent — Verify if a linked account exists: Before attempting to establish a link, the agent can check whether the buyer already has a linked account with the merchant. Google sends a JWT assertion to the merchant's token endpoint with `intent: check` and the buyer's identifier (typically their Google account email or sub). The merchant returns whether a matching account exists. This avoids unnecessarily initiating an OAuth flow if the buyer is already linked.
`create` intent — Establish a new account link: If no linked account exists and the buyer wants to link their merchant account, the agent initiates the OAuth 2.0 Authorization Code flow. The buyer is redirected to the merchant's authorisation endpoint, authenticates with their merchant credentials, and consents to the linking scope. The merchant issues an authorisation code; Google exchanges this for access and refresh tokens via the token endpoint, with a JWT assertion carrying `intent: create`. The link is established and stored — future sessions for this buyer can use the `get` intent to retrieve tokens without repeating the full OAuth flow.
`get` intent — Retrieve tokens for an existing link: For buyers with an established account link, Google sends a JWT assertion to the merchant's token endpoint with `intent: get` and the buyer's identifier. The merchant returns the current access token (and optionally a refreshed token if the existing one is near expiry). The agent uses this token to make authenticated requests to the merchant's UCP endpoints — for example, retrieving the buyer's stored addresses or applying their loyalty discount in the cart.
---
Technical Requirements for Identity Linking
Merchants implementing UCP identity linking must meet the following requirements from Google's specification:
Token endpoint: The merchant must implement a token endpoint that accepts JWT assertions from Google using HTTP Basic Authentication (client ID and client secret). The endpoint handles all three intent types (`check`, `create`, `get`) at a single URL.
Authorization endpoint: For the `create` flow, the merchant must implement an OAuth 2.0 Authorization Code endpoint where the buyer can authenticate and consent to the linking scope.
JWT verification: The merchant must verify the JWT assertions sent by Google, confirming they are signed with Google's private key (verified against Google's published JWKS endpoint) before processing the intent request.
Scope declaration: The merchant declares the OAuth 2.0 scopes their identity linking implementation supports in the UCP profile. Scopes typically cover access to stored addresses, order history, and loyalty account data.
HTTPS-only: All identity linking endpoints must use HTTPS. No plain HTTP traffic is permitted in the identity linking flow.
---
The Buyer Consent Model
UCP identity linking is grounded in explicit buyer consent at the OAuth 2.0 authorisation step. The buyer is not linked to a merchant account automatically or without awareness — they must actively authenticate at the merchant's authorisation endpoint and consent to the requested OAuth 2.0 scopes.
The consent interface is hosted and controlled by the merchant, not by Google or the AI agent. The merchant's authorisation endpoint presents the buyer with a clear description of what data access the agent is requesting (stored addresses, order history, etc.) and the buyer must approve this before the authorisation code is issued. This means the buyer's consent is mediated by the merchant's own interface, using the merchant's own account authentication, rather than being assumed or bypassed by the agent layer.
Buyers can unlink their accounts at any time. The UCP identity linking specification includes an `unlink` operation that removes the token association, after which the buyer's UCP interactions with that merchant revert to guest sessions.
---
Why It Matters for Merchants
Identity linking converts an AI agent from a generic purchase channel into a personalised one. A buyer who has linked their account gets their stored address pre-filled in cart and checkout sessions, sees their loyalty points balance reflected in pricing, and has access to their order history within the agent interface. This experience is meaningfully better than guest checkout and increases the likelihood of repeat purchases through the agentic channel.
Identity linking also gives merchants better customer intelligence from the agentic channel. Rather than receiving orders from anonymous buyers, merchants receive orders associated with known customer accounts — enabling post-purchase CRM sequences, loyalty point attribution, and cohort analysis of AI-referred buyers.
The optional nature of identity linking means merchants can launch UCP with guest checkout only, gain operational experience with the agentic channel, and then add identity linking as a subsequent investment when the volume and customer mix justifies the additional implementation work.
---
FeedBridge Relevance
FeedBridge supports UCP identity linking as part of its live UCP protocol stack. The platform includes an Identity Linking API — a `POST` endpoint for link/unlink buyer account operations — with an OAuth 2.0 stub. This stub provides the structural endpoint and token handling framework that merchants need to connect their own identity and authentication systems.
Merchants using FeedBridge's UCP implementation have identity linking declared as an available capability in their `/.well-known/ucp` manifest, visible in the UCP Dashboard Hub's compliance scorecard and capability checklist. The implementation scope of the OAuth 2.0 stub — specifically the connection to the merchant's own identity provider and the JWT verification logic for Google's assertions — must be completed by the merchant's engineering team or through an identity provider integration.
---
Frequently Asked Questions
Q: Is identity linking required for UCP checkout? A: No. Guest checkout is the default UCP checkout path and requires no identity linking implementation. Identity linking is an optional capability for merchants who want to support account-linked, personalised checkout. Merchants can go live on UCP without identity linking and add it later.
Q: Does Google store the buyer's merchant account credentials? A: No. The OAuth 2.0 flow means that the buyer authenticates directly with the merchant's authorisation endpoint. Google receives only the access and refresh tokens issued by the merchant — it never receives or stores the buyer's merchant account password.
Q: What data can an agent access after identity linking? A: The data the agent can access is determined by the OAuth 2.0 scopes the merchant declares and the buyer consents to during the `create` flow. Typical scopes include stored addresses, order history, and loyalty account data. The merchant controls what is exposed by what scopes they offer.
Q: Can a buyer be linked to the same merchant account across multiple AI platforms? A: In principle, yes — each AI platform that supports UCP identity linking would initiate its own OAuth 2.0 linking flow, resulting in separate tokens for each platform. The buyer would need to complete the `create` flow once per platform. The merchant's token endpoint handles all platform requests uniformly, as they all use the same JWT assertion format with `intent: create`.
Q: What happens to the link if the buyer's access token expires? A: Merchants should issue both access tokens (short-lived) and refresh tokens (long-lived) during the `create` flow. When an access token expires, the agent uses the `get` intent to obtain a refreshed token from the merchant's token endpoint without requiring the buyer to re-authenticate. Merchants must implement token refresh logic at their token endpoint to support this flow.
---
Related Topics
Parent hub: UCP Identity
Related concepts:
- What Is UCP?
- How UCP Powers Agentic Checkout
- UCP Across the Full Shopping Journey
- UCP Merchant Center Onboarding Explained
Breadcrumb:
---
Source Documentation
| Claim | Source | Source Class | Reference | |---|---|---|---| | Identity linking uses OAuth 2.0 Authorization Code flow (RFC 6749), HTTP Basic Authentication at token endpoint | Google UCP Identity Linking Guide | T1 – Official UCP Docs | https://developers.google.com/merchant/ucp/guides/identity-linking | | JWT assertions combine intent checks and token exchange; intent types: check, create, get | Google UCP Identity Linking Guide | T1 – Official UCP Docs | https://developers.google.com/merchant/ucp/guides/identity-linking | | Guest checkout is default; identity linking is optional | Google UCP Guide | T1 – Official UCP Docs | https://developers.google.com/merchant/ucp/guides | | FeedBridge Identity Linking API: POST, link/unlink, OAuth 2.0 stub — live | FeedBridge Platform Capabilities April 2026 v2.0 | T1 – FeedBridge Internal | FeedBridge-Platform-Capabilities-April2026.md |