Skip to main content
rchaumais
Level 1
August 15, 2026
Solved

Analytics MCP server: can a third-party app connect with the customer's own OAuth User credentials?

  • August 15, 2026
  • 2 replies
  • 95 views

Hello,

 

We run allmates.ai, an enterprise AI assistant platform. Several of our customers use Adobe Analytics and Customer Journey Analytics, and would like to reach the Analytics MCP servers (https://aa-mcp.adobe.io/mcp and https://cja-mcp.adobe.io/mcp) from our product.

 

The dynamic client registration endpoint advertised in the authorization-server metadata only accepts an allowlist of partner redirect URIs (claude.ai, chatgpt.com, cursor.com, plus loopback addresses), so our own callback is rejected. Rather than asking to be added to that list, we would like to follow what looks like the intended path for customers: each customer creates its own OAuth application, and we use those credentials.

 

The setup we plan to document for our customers:

 

1. An Adobe administrator adds the MCP Access permission item to the relevant product profile, and adds the developer on the Developers tab.

2. That developer creates a Developer Console project, adds the Adobe Analytics (or CJA) API, and creates an OAuth User authentication credential on the Web App platform.

3. They declare our redirect URI in that credential, and give us the client ID and the client secret.

4. Our platform runs the authorization code + PKCE flow against ims-na1.adobelogin.com, requesting openid, AdobeID and additional_info.projectedProductContext, and each of their users signs in with their own Adobe ID.

 

Questions:

 

1. Is this a supported way to reach the MCP servers, i.e. does the MCP server accept an IMS user token issued to a client credential it did not register itself?

2. With a user token, are the x-api-key and x-gw-ims-org-id headers expected, as they are in the documented server-to-server flow? Is x-global-company-id required for Adobe Analytics, or is setSessionDefaults the intended way to select the company?

3. User authentication credentials start In Development, where only listed beta users can sign in, and the documentation states that an application can serve Adobe users with a company or school account only after an Adobe review. Does a customer need that review to let its own employees sign in to its own application? This is the point that decides whether each customer can set this up on its own.

4. Are any scopes needed beyond the three above?

 

The same question is open on GitHub, on AdobeDocs/analytics-2.0-apis (issue 721) and AdobeDocs/analytics-mcp (issue 12).

 

Thank you,

Romain Chaumais, allmates.ai

Best answer by PrasanthV

Hi ​@rchaumais,

Here is the technical breakdown to address each of your questions regarding the Adobe Analytics & CJA MCP Server integration via custom customer-owned OAuth Web App credentials.

1. Is this a supported path for third-party platforms?

Yes. The Model Context Protocol (MCP) servers (aa-mcp.adobe.io and cja-mcp.adobe.io) evaluate incoming requests using standard Adobe IMS OAuth User Access Tokens.

The MCP endpoint does not mandate that the token originate from a specific pre-registered Adobe partner Client ID. As long as:

  • The token is a valid, unexpired IMS User Token (Authorization Code + PKCE flow).

  • The user's account has been granted the MCP Access permission item inside Adobe Admin Console.

  • The Developer Console project includes the Adobe Analytics / CJA API service.

The MCP gateway will accept and validate the bearer token regardless of which OAuth Client ID issued it.

2. Header Requirements (x-api-key, x-gw-ims-org-id, x-global-company-id)

When connecting to the Analytics/CJA MCP server with a User Token (3-legged OAuth):

  • Authorization: Bearer <access_token> (Required)

  • x-api-key: <customer_client_id> (Required) – Must match the Client ID of the Developer Console project where the API was added.

  • x-gw-ims-org-id: <ims_org_id@AdobeOrg> (Required) – The target IMS Organization ID.

  • x-global-company-id (Adobe Analytics specific):

    • If the user belongs to a single AA company, the MCP server can automatically infer it.

    • If the user belongs to multiple login companies, passing x-global-company-id as a header (or invoking the setSessionDefaults tool on initial connection) prevents ambiguous 403 Forbidden or context errors. Passing x-global-company-id explicitly on the initial connection header is recommended.

3. Developer Console App Status ("In Development" vs. Adobe Review)

No, an internal customer does NOT need an official Adobe App Review.

The Adobe App Review process is strictly required for multi-tenant ISV applications that intend to publish to the public Adobe App Exchange or allow external, uninvited third-party Adobe users to log in.

For internal enterprise deployments:

  • When a customer creates an OAuth Web App credential inside their own enterprise Developer Console Org, all users belonging to that same IMS Org / Enterprise Directory are treated as Internal Users.

  • Employees signing in with their company Federated ID / Enterprise ID can authenticate through the OAuth PKCE flow without hitting the "In Development" beta user block, provided the developer console project lives inside their enterprise organization context.

4. Required OAuth Scopes

Your listed scopes are almost complete, but you should include the explicit API scope for Analytics / CJA to prevent token scope truncation:

  • openid

  • AdobeID

  • additional_info.projectedProductContext

  • read_organizations (Recommended)

  • read_pc (Product Context scope – required to fetch user entitlements)

For Adobe Analytics specifically, ensure your authorization request includes the explicit scope string or target API context:

scope=openid,AdobeID,read_organizations,additional_info.projectedProductContext,read_p

2 replies

PrasanthVAccepted solution
Level 4
August 25, 2026

Hi ​@rchaumais,

Here is the technical breakdown to address each of your questions regarding the Adobe Analytics & CJA MCP Server integration via custom customer-owned OAuth Web App credentials.

1. Is this a supported path for third-party platforms?

Yes. The Model Context Protocol (MCP) servers (aa-mcp.adobe.io and cja-mcp.adobe.io) evaluate incoming requests using standard Adobe IMS OAuth User Access Tokens.

The MCP endpoint does not mandate that the token originate from a specific pre-registered Adobe partner Client ID. As long as:

  • The token is a valid, unexpired IMS User Token (Authorization Code + PKCE flow).

  • The user's account has been granted the MCP Access permission item inside Adobe Admin Console.

  • The Developer Console project includes the Adobe Analytics / CJA API service.

The MCP gateway will accept and validate the bearer token regardless of which OAuth Client ID issued it.

2. Header Requirements (x-api-key, x-gw-ims-org-id, x-global-company-id)

When connecting to the Analytics/CJA MCP server with a User Token (3-legged OAuth):

  • Authorization: Bearer <access_token> (Required)

  • x-api-key: <customer_client_id> (Required) – Must match the Client ID of the Developer Console project where the API was added.

  • x-gw-ims-org-id: <ims_org_id@AdobeOrg> (Required) – The target IMS Organization ID.

  • x-global-company-id (Adobe Analytics specific):

    • If the user belongs to a single AA company, the MCP server can automatically infer it.

    • If the user belongs to multiple login companies, passing x-global-company-id as a header (or invoking the setSessionDefaults tool on initial connection) prevents ambiguous 403 Forbidden or context errors. Passing x-global-company-id explicitly on the initial connection header is recommended.

3. Developer Console App Status ("In Development" vs. Adobe Review)

No, an internal customer does NOT need an official Adobe App Review.

The Adobe App Review process is strictly required for multi-tenant ISV applications that intend to publish to the public Adobe App Exchange or allow external, uninvited third-party Adobe users to log in.

For internal enterprise deployments:

  • When a customer creates an OAuth Web App credential inside their own enterprise Developer Console Org, all users belonging to that same IMS Org / Enterprise Directory are treated as Internal Users.

  • Employees signing in with their company Federated ID / Enterprise ID can authenticate through the OAuth PKCE flow without hitting the "In Development" beta user block, provided the developer console project lives inside their enterprise organization context.

4. Required OAuth Scopes

Your listed scopes are almost complete, but you should include the explicit API scope for Analytics / CJA to prevent token scope truncation:

  • openid

  • AdobeID

  • additional_info.projectedProductContext

  • read_organizations (Recommended)

  • read_pc (Product Context scope – required to fetch user entitlements)

For Adobe Analytics specifically, ensure your authorization request includes the explicit scope string or target API context:

scope=openid,AdobeID,read_organizations,additional_info.projectedProductContext,read_p
manpreetkaur27
Adobe Support
manpreetkaur27Adobe Support
Adobe Support
September 2, 2026

Thanks for sharing the detailed answers, ​@PrasanthV 

Terms & ConditionsAccessibility statement

Loading footer...