API Token Acquisition Issue for Multi-Tenant App (AME/MSFT Scenarios)

Question

API Token Acquisition Issue for Multi-Tenant App (AME/MSFT Scenarios)

Vikram Kumar 0 Microsoft Employee

The Web API service is currently deployed in AME and supports use cases across both AME and MSFT tenants. To enable this, I have configured a multi-tenant app registration, and cross-tenant (MSFT → AME) calls are working as expected. However, for AME-to-AME scenarios, the flow requires a token exchange before forwarding the request. I’m currently unable to find a clear approach or documentation on how to implement this token exchange within AME, particularly for Synapse, IcM, or Logic App workflow connectors. Can you suggest how to invoke the API using these connectors while acquiring the required authentication token? Could you please help with: Recommended approach for handling token exchange in AME-to-AME calls for synapse or IcM or logic app workflow connector.

C Tulasi Prasad 0 Reputation points

2026-06-09T06:44:00.4666667+00:00
For AME-to-AME scenarios, the key question is what identity the downstream API expects and whether the connector can obtain a token directly for that resource. In most cases, you should try to avoid a custom "token exchange" step unless the platform specifically requires an OBO (On-Behalf-Of) flow.

1. Recommended Architecture

Preferred approach:

Instead of:

Use a service principal or managed identity to directly request a token for the API's Application ID URI (audience).

2. Logic Apps

For Logic Apps, you have three common options:

Option A – Managed Identity (Recommended)

Enable System-Assigned Managed Identity on the Logic App.

Grant the Logic App MI access to the API App Registration.

Use HTTP action with Managed Identity authentication.

Example:

The Logic App automatically acquires the token.

Option B – Service Principal

Store:

Client ID

Client Secret

Tenant ID

in Key Vault.

Acquire token:

Pass:

to your API.

3. Synapse

For Synapse Pipelines:

Web Activity

First call AAD:

Request:

Store access token in pipeline variable.

Then call API:

Synapse Managed Identity

If your API trusts managed identities:

Enable Synapse Workspace Managed Identity.

Grant API permissions.

Acquire token using MSI endpoint or linked service authentication.

This is usually cleaner than implementing token exchange.

4. IcM Connector

For IcM integrations, the typical pattern is:

Register a confidential client application.

Configure OAuth 2.0 client credentials.

Acquire token for:

Attach token in outbound API call.

If IcM must propagate the caller's identity, then you may need an OAuth On-Behalf-Of (OBO) flow rather than client credentials.

5. When Token Exchange Is Actually Needed

You generally need token exchange/OBO only when:

User authenticates to Connector A.

Connector A calls API B.

API B must know the original user identity.

Flow:

This requires:

and the original user access token.For AME-to-AME scenarios, the key question is what identity the downstream API expects and whether the connector can obtain a token directly for that resource. In most cases, you should try to avoid a custom "token exchange" step unless the platform specifically requires an OBO (On-Behalf-Of) flow.

1. Recommended Architecture

Preferred approach:

Instead of:

Use a service principal or managed identity to directly request a token for the API's Application ID URI (audience).

2. Logic Apps

For Logic Apps, you have three common options:

Option A – Managed Identity (Recommended)

Enable System-Assigned Managed Identity on the Logic App.

Grant the Logic App MI access to the API App Registration.

Use HTTP action with Managed Identity authentication.

Example:

The Logic App automatically acquires the token.

Option B – Service Principal

Store:

Client ID

Client Secret

Tenant ID

in Key Vault.

Acquire token:

Pass:

to your API.

3. Synapse

For Synapse Pipelines:

Web Activity

First call AAD:

Request:

Store access token in pipeline variable.

Then call API:

Synapse Managed Identity

If your API trusts managed identities:

Enable Synapse Workspace Managed Identity.

Grant API permissions.

Acquire token using MSI endpoint or linked service authentication.

This is usually cleaner than implementing token exchange.

4. IcM Connector

For IcM integrations, the typical pattern is:

Register a confidential client application.

Configure OAuth 2.0 client credentials.

Acquire token for:

Attach token in outbound API call.

If IcM must propagate the caller's identity, then you may need an OAuth On-Behalf-Of (OBO) flow rather than client credentials.

5. When Token Exchange Is Actually Needed

You generally need token exchange/OBO only when:

User authenticates to Connector A.

Connector A calls API B.

API B must know the original user identity.

Flow:

This requires:

and the original user access token.
Shubham Sharma 17,065 Reputation points Microsoft External Staff Moderator

2026-06-09T07:07:13.3266667+00:00

Hello Vikram KumarThank you for contacting us . We have begun looking into it and will share our suggestions with you as soon as possible.
VEMULA SRISAI 13,220 Reputation points Microsoft External Staff Moderator

2026-06-09T07:20:18.8633333+00:00

Hello Vikram Kumar, From your description, the behavior is expected. In AME-to-AME scenarios, access tokens are tenant-issued and cannot be directly forwarded across components, which is why a token exchange (or re-acquisition) is required.

At present, connectors such as Synapse, Logic Apps, and IcM workflows do not support native token exchange or on-behalf-of (OBO) flows. They can only acquire tokens for a target resource and do not provide a mechanism to exchange an incoming token context within the workflow itself.

The recommended approach is to avoid token forwarding and instead implement a backend token acquisition pattern. Typically, this is done by introducing an intermediate API (token broker) or using Managed Identity / client credentials, where the downstream API is invoked using a freshly acquired token within the same tenant.

You will also need to ensure that the target API has a valid service principal in the tenant and the correct scopes/app roles are configured, as token validation depends on proper service principal presence and configuration.

In summary, for Synapse, Logic Apps, or IcM scenarios, the supported pattern is to acquire a new token (using Managed Identity or app credentials) rather than attempting token exchange within the connector flow.

Your answer

Shubham Sharma 17,065 Reputation points Microsoft External Staff Moderator

2026-06-09T07:07:13.3266667+00:00

Hello Vikram KumarThank you for contacting us . We have begun looking into it and will share our suggestions with you as soon as possible.
VEMULA SRISAI 13,220 Reputation points Microsoft External Staff Moderator

2026-06-09T07:20:18.8633333+00:00

Hello Vikram Kumar, From your description, the behavior is expected. In AME-to-AME scenarios, access tokens are tenant-issued and cannot be directly forwarded across components, which is why a token exchange (or re-acquisition) is required.

At present, connectors such as Synapse, Logic Apps, and IcM workflows do not support native token exchange or on-behalf-of (OBO) flows. They can only acquire tokens for a target resource and do not provide a mechanism to exchange an incoming token context within the workflow itself.

The recommended approach is to avoid token forwarding and instead implement a backend token acquisition pattern. Typically, this is done by introducing an intermediate API (token broker) or using Managed Identity / client credentials, where the downstream API is invoked using a freshly acquired token within the same tenant.

You will also need to ensure that the target API has a valid service principal in the tenant and the correct scopes/app roles are configured, as token validation depends on proper service principal presence and configuration.

In summary, for Synapse, Logic Apps, or IcM scenarios, the supported pattern is to acquire a new token (using Managed Identity or app credentials) rather than attempting token exchange within the connector flow.

Share via

API Token Acquisition Issue for Multi-Tenant App (AME/MSFT Scenarios)

1. Recommended Architecture

2. Logic Apps

Option A – Managed Identity (Recommended)

Option B – Service Principal

3. Synapse

Web Activity

Synapse Managed Identity

4. IcM Connector

5. When Token Exchange Is Actually Needed

1. Recommended Architecture

2. Logic Apps

Option A – Managed Identity (Recommended)

Option B – Service Principal

3. Synapse

Web Activity

Synapse Managed Identity

4. IcM Connector

5. When Token Exchange Is Actually Needed

Your answer