APP service call to APIM with managed identity

Question

APP service call to APIM with managed identity

Nagpal, Rita 131

Hi,

We host our React application in Azure App Service using the BFF (Backend-for-Frontend) pattern. All microservices are deployed in AKS and secured through APIM. Since there are no direct browser-to-backend calls, all service requests are routed through the App Service.

Is it possible to enable a Managed Identity on the App Service, configure APIM to trust that identity, and then have the App Service call backend services using only the APIM endpoint? In this scenario, would APIM automatically acquire and attach the required access token when forwarding requests to the backend services?

Nagpal, Rita 131 Reputation points

2026-11-03T09:59:07.42+00:00

THanks Ajay for reply...Could you provide a bit more clarification on the below use case?

Since the traffic flow is entirely within Azure (App Service → APIM → AKS), would the following approach work?

If we enable Managed Identity on APIM and grant the required access, can App Service call the APIM endpoint, where APIM authenticates the request using the configured client identity and then forwards it to the AKS backend? On the AKS ingress side, authentication would be validated based on the same client identity.

Our primary objective is to implement an infrastructure-level authentication solution without requiring any code changes to the React application currently hosted in App Service. We are looking to avoid application-level token handling and instead leverage Azure-native authentication mechanisms between App Service, APIM, and AKS

Answer accepted by question author

SHOUMIK CHAKRAVARTY 1,455

Hi @Nagpal, Rita

Yes to the first question, and no to the second.

Inbound (App Service to APIM)

This works. Register an Entra application for the API, have the App Service managed identity request a token for that resource, and validate it in APIM with validate-azure-ad-token, which “enforces the existence and validity of a JSON web token (JWT) that was provided by the Microsoft Entra ... service for a specified set of principals in the directory.” List the App Service identity under client-application-ids or the API’s application ID under audiences. This runs inbound at any scope.

Outbound (APIM to AKS)

APIM does not acquire a token for you. The reference mentions it : “Token forwarding is the customer’s responsibility.” If your AKS service needs one, authentication-managed-identity “uses the managed identity to obtain an access token from Microsoft Entra ID for accessing the specified resource” and then “will set the value of the token in the Authorization header using the Bearer scheme.” APIM caches that token until it expires.

Two implications:

If you add that policy, the backend sees APIM’s identity rather than the App Service’s, because the policy sets the Authorization header. If you need the original caller’s identity downstream, carry it in a separate header.
“API Management doesn’t validate which backend the token is sent to”, so restricting which backends can receive it is on you.

If AKS does not require an Entra token, you do not need the outbound policy at all.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

Nagpal, Rita 131 Reputation points

2026-11-03T09:56:44.9066667+00:00

Thanks Shoumik for your reply, that's really useful, Could you provide a bit more clarification on the below use case?

Since the traffic flow is entirely within Azure (App Service → APIM → AKS), would the following approach work?

If we enable Managed Identity on APIM and grant the required access, can App Service call the APIM endpoint, where APIM authenticates the request using the configured client identity and then forwards it to the AKS backend? On the AKS ingress side, authentication would be validated based on the same client identity.

Our primary objective is to implement an infrastructure-level authentication solution without requiring any code changes to the React application currently hosted in App Service. We are looking to avoid application-level token handling and instead leverage Azure-native authentication mechanisms between App Service, APIM, and AKS.
SHOUMIK CHAKRAVARTY 1,455 Reputation points

2026-11-04T01:53:55.2166667+00:00

The identity on the first hop is the App Service’s, not APIM’s. App Service requests a token for the Entra application that represents the API, and APIM simply validates that token with validate-azure-ad-token. Turning on a managed identity for APIM does not change how that inbound check works.

For the second hop, APIM’s managed identity is the right tool. The authentication-managed-identity policy lets APIM request a token for the backend resource and place it in the Authorization header, without any application code.

The part that does not carry through is AKS validating the same client identity. Once the outbound policy runs, the Authorization header contains APIM’s token, so your ingress sees APIM as the caller. If you need the original caller’s identity downstream, you can copy it into a separate header before the outbound policy executes.

If AKS does not need an Entra token, you can skip the outbound policy entirely.
Nagpal, Rita 131 Reputation points

2026-11-04T09:56:05.1933333+00:00

THank Shoumik !! I have received some guidance on this solution. One additional point regarding App Service token requests: we would like to use the Managed Identity client ID for token acquisition and eliminate the need to pass client secrets. This would require enabling Managed Identity on both the App Service and APIM resources, and granting the necessary permissions and access.
SHOUMIK CHAKRAVARTY 1,455 Reputation points

2026-11-04T15:24:14.5933333+00:00

Yes, that should removes client secrets entirely. The App Service managed identity requests the token itself, and with a user-assigned identity you pass its client ID on the request.
Nagpal, Rita 131 Reputation points

2026-11-04T15:58:08.2333333+00:00

Thanks for confirming, that's really helpful...

1 additional answer

Your answer

Nagpal, Rita 131 Reputation points

2026-11-03T09:59:07.42+00:00

THanks Ajay for reply...Could you provide a bit more clarification on the below use case?

Since the traffic flow is entirely within Azure (App Service → APIM → AKS), would the following approach work?

If we enable Managed Identity on APIM and grant the required access, can App Service call the APIM endpoint, where APIM authenticates the request using the configured client identity and then forwards it to the AKS backend? On the AKS ingress side, authentication would be validated based on the same client identity.

Our primary objective is to implement an infrastructure-level authentication solution without requiring any code changes to the React application currently hosted in App Service. We are looking to avoid application-level token handling and instead leverage Azure-native authentication mechanisms between App Service, APIM, and AKS
Nagpal, Rita 131 Reputation points

2026-11-03T09:56:44.9066667+00:00

Thanks Shoumik for your reply, that's really useful, Could you provide a bit more clarification on the below use case?

Since the traffic flow is entirely within Azure (App Service → APIM → AKS), would the following approach work?

If we enable Managed Identity on APIM and grant the required access, can App Service call the APIM endpoint, where APIM authenticates the request using the configured client identity and then forwards it to the AKS backend? On the AKS ingress side, authentication would be validated based on the same client identity.

Our primary objective is to implement an infrastructure-level authentication solution without requiring any code changes to the React application currently hosted in App Service. We are looking to avoid application-level token handling and instead leverage Azure-native authentication mechanisms between App Service, APIM, and AKS.
SHOUMIK CHAKRAVARTY 1,455 Reputation points

2026-11-04T01:53:55.2166667+00:00

The identity on the first hop is the App Service’s, not APIM’s. App Service requests a token for the Entra application that represents the API, and APIM simply validates that token with validate-azure-ad-token. Turning on a managed identity for APIM does not change how that inbound check works.

For the second hop, APIM’s managed identity is the right tool. The authentication-managed-identity policy lets APIM request a token for the backend resource and place it in the Authorization header, without any application code.

The part that does not carry through is AKS validating the same client identity. Once the outbound policy runs, the Authorization header contains APIM’s token, so your ingress sees APIM as the caller. If you need the original caller’s identity downstream, you can copy it into a separate header before the outbound policy executes.

If AKS does not need an Entra token, you can skip the outbound policy entirely.
Nagpal, Rita 131 Reputation points

2026-11-04T09:56:05.1933333+00:00

THank Shoumik !! I have received some guidance on this solution. One additional point regarding App Service token requests: we would like to use the Managed Identity client ID for token acquisition and eliminate the need to pass client secrets. This would require enabling Managed Identity on both the App Service and APIM resources, and granting the necessary permissions and access.
SHOUMIK CHAKRAVARTY 1,455 Reputation points

2026-11-04T15:24:14.5933333+00:00

Yes, that should removes client secrets entirely. The App Service managed identity requests the token itself, and with a user-assigned identity you pass its client ID on the request.
Nagpal, Rita 131 Reputation points

2026-11-04T15:58:08.2333333+00:00

Thanks for confirming, that's really helpful...

Answer 1

Hi @Nagpal, Rita

Greetings for the day, Thanks for reaching out to Q&A.

Glad hop 1, option 2 works for your setup. Here's a short summary of the final design so it's easy for you and anyone else who finds this thread to follow.

Hop 1: App Service (BFF) → APIM, using the App Service managed identity

Get the token in the BFF's server-side code, not in the React browser bundle. Use DefaultAzureCredential or the local IDENTITY_ENDPOINT with the App Service managed identity. If it's user-assigned, pass its client ID. Request the token for the APIM-facing app registration's audience. No client secret is needed. ✔ To verify: decode the token and check that aud matches the APIM-facing app and appid/azp matches the App Service managed identity's client ID.
Validate the token in APIM. In the inbound section, add validate-azure-ad-token and list the App Service managed identity's client ID under client-application-ids. ✔ To verify: a call with no token, or with another identity's token, returns 401 from APIM.

Hop 2: APIM → AKS, configuration only

Have APIM get a token with its own managed identity. Enable a managed identity on APIM. Add authentication-managed-identity after validate-azure-ad-token, with resource set to the backend app registration's ID or Application ID URI. This order matters: APIM checks the incoming token before it replaces the Authorization header. ✔ To verify: an APIM test-console trace shows the backend request with a Bearer token whose aud matches the backend app.
Validate the token at the AKS ingress. Check that aud is the backend app and the caller is APIM's managed identity. AKS will see APIM's identity, not the App Service's. If the backend needs the original caller's identity, have APIM send it in a custom header. ✔ To verify: a direct call to the ingress without a token returns 401.

If you hit a 401 at either hop while rolling this out, post the decoded token claims (aud, appid/azp, iss) and the APIM trace output in a new thread, with secrets and tenant-specific values removed. We can usually find the mismatch quickly from those.

If this answer helped resolve your question, please upvote it so other community members with the same App Service → APIM → AKS setup can find it more easily.