Comparing On-Behalf-Of vs Managed Identity mechanisms for service to service calls on Azure API Management

Understanding the On-Behalf-Of (OBO) Flow

The On-Behalf-Of (OBO) flow is designed for scenarios where an application or service (the "middle-tier API" or "client application") calls another downstream API on behalf of a user who has already authenticated to the middle-tier.

The key characteristic of OBO is identity propagation: the original user's identity flows through every service in the call chain. This is critical when downstream APIs need to enforce user-specific authorization - for example, "can this specific user access this specific resource?"

OBO Flow Visualization

Key Components of the OBO Flow

1. User Authentication: A user signs into a web application (the client application).
2. Initial Token: The web application receives an access token (Token A) that represents the user's identity and session with the web app.
3. Downstream Call Needed: The web application needs to call a backend API (Downstream API 1) to get data related to that user.
4. OBO Token Exchange: The web application takes Token A and exchanges it with Microsoft Entra ID for a new access token (Token B). This exchange requires both the original token and the client application's own credentials.
5. Call Downstream API: The web application uses Token B to call Downstream API 1.
6. Identity Propagation: Downstream API 1 can validate Token B and see that the call is from the web application but is acting on behalf of the original user. The downstream API can extract both the application identity and the user identity from the token claims.

When to Use OBO

• The downstream API needs to know who the user is to enforce user-level authorization
• You need an audit trail that traces actions back to specific users
• Different users should have different access levels to the same API
• You're building multi-tier applications where user context must flow through the entire stack

Understanding the Managed Identity Flow

Managed Identity takes a fundamentally different approach. Instead of propagating user identity, the calling service authenticates as itself using an identity automatically managed by Azure. There are no secrets to manage, rotate, or store - Azure handles the credentials entirely behind the scenes.

This pattern is ideal for service-to-service communication where the downstream API doesn't need to know (or care) about the original user. The authorization model shifts from "what can this user do?" to "what can this service do?"

Managed Identity Flow Visualization

Key Components of the Managed Identity Flow

1. User Request Arrives: A user makes a request to the client application. The user may be authenticated, but their identity won't be forwarded to downstream services.
2. Token Acquisition via IMDS: When the client app needs to call a downstream API, it requests a token from the Azure Instance Metadata Service (IMDS). This is a local endpoint (169.254.169.254) available only from within Azure - no secrets required.
3. Azure-Managed Authentication: IMDS coordinates with Microsoft Entra ID using the service's managed identity. Azure handles all credential management automatically.
4. Service Token Issued: Entra ID issues an access token where the identity is the service itself, not any user. The token audience is set to the downstream API.
5. Service-to-Service Call: The client app calls the downstream API through APIM using this token.
6. Service-Level Authorization: The downstream API validates the token and authorizes based on the calling service's identity. It has no visibility into the original user.

When to Use Managed Identity

• The downstream API doesn't need user context - it trusts the calling service to have already handled user authorization
• You want to eliminate secret management entirely (no passwords, certificates, or connection strings)
• You're performing background jobs, data synchronization, or administrative operations where user context is irrelevant
• You want simplified operations - no credential rotation, no secret expiry alerts
• The calling service runs within Azure (VMs, App Service, Functions, AKS, etc.)

Choosing Between OBO and Managed Identity

The choice between these two patterns comes down to a single question: does the downstream API need to know who the user is?

Hybrid Approach

In practice, many architectures use both patterns. For example:

• Frontend → Azure API Management: OBO flow (user identity matters for personalization)
• Azure API Management → Backend Services: Managed Identity (backend trusts APIM's authorization decisions)

This hybrid approach lets you maintain user context where it's needed while simplifying service-to-service communication in your backend.