How to implement the on-behalf-of (OBO) flow with Azure API Management
Learn how to utilize Microsoft Azure's API Management to implement the on-behalf-of (OBO) flow
Welcome back to System Shogun! In this blog post, we'll explore a practical use case for the OAuth 2.0 On-Behalf-Of (OBO) flow. I recently created a YouTube video where I walk through this scenario, demonstrating how a client application can securely access multiple downstream services like Azure Key Vault and Storage Account using Azure API Management (APIM) with App Service Web App and Azure Functions behind it. You can watch the whole thing on YouTube.
Let's break down the use case with the help of the architecture diagram I designed and discuss how OBO flow ensures secure token passing across services.
Understanding the Use Case
Imagine you have a client application that needs to:
Access APIs hosted behind Azure APIM.
Trigger an Azure Durable Function workflow.
Retrieve secrets from Azure Key Vault.
Access files in Azure Storage Account.
Each of these services requires specific permissions and secure token handling. The On-Behalf-Of (OBO) flow ensures that each service can act on behalf of the signed-in user without exposing credentials or managing multiple access tokens manually.
Importantly, the APIs themselves do not have access to these downstream services. This significantly improves security because access is solely based on the signed-in user’s permissions. Without the OBO flow, anyone with access to the APIs could potentially access other services. The OBO approach places the responsibility on the user to have the required permissions for all accessed services, ensuring that only authorized users can interact with sensitive resources.
Architecture Breakdown
Here's how the flow works:
Client Authentication:
The user signs in to the Client Application.
The app obtains an access token with
apim.access.readwrite
scope from Azure Entra ID.
Calling Azure APIM:
The client calls Azure APIM, passing the acquired access token.
APIM's On-Behalf-Of Flow:
APIM uses the OBO flow to get access tokens for downstream services (API or Durable Function) with required scopes (
api1.readwrite
ordfunc1.readwrite
).
Downstream API Call:
APIM forwards the on-behalf-of token to the API.
Accessing Key Vault Securely:
The API uses the OBO flow to obtain a token with scope
https://vault.azure.net/.default
to call Azure Key Vault.
Calling Azure Durable Function:
APIM may also trigger the Durable Function, passing the OBO token.
The Durable Function uses OBO to obtain a token for Azure Storage Account with scope
https://storage.azure.net/.default
.
Final Access:
The Durable Function accesses the Storage Account on behalf of the user with the required scope.
Key Notes:
Proper app registrations and role assignments are critical in Azure Entra ID.
Azure Key Vault and Storage Account permissions must be included in the app registrations.
Why Use the On-Behalf-Of Flow?
The OBO flow simplifies secure multi-tier authentication without:
Hardcoding credentials.
Manually exchanging tokens.
Repeated user prompts for authentication.
By chaining token exchanges, each service receives a token scoped only to what it needs, adhering to the principle of least privilege and improving overall system security.
Real-World Scenarios
Enterprise APIs: Where a frontend app calls backend APIs, which then need to access sensitive data in Key Vault.
Serverless Workflows: Durable Functions triggered by APIM, processing files in Storage Accounts securely.
Multi-Tier Microservices: Ensuring each microservice has scoped access while maintaining user context.
This ensures that the access rights, permissions, and security policies applied to the user are consistently enforced across all downstream services, preventing unauthorized access to the service.
Watch the Full Demo
I've recorded a full walkthrough of this use case, including:
Live demo of the OBO flow.
Real code snippets using Microsoft.Identity.Web and Azure SDKs.
Step-by-step troubleshooting tips.
Final Thoughts
The On-Behalf-Of flow is a powerful pattern for secure, delegated access across multiple Azure services. In scenarios like this, where a client app needs to interact with several APIs and backend resources, OBO ensures:
Seamless user experience with single authentication.
Improved security with minimal exposure of credentials.
Scalable architectures aligned with Azure best practices.
For more detailed content, real-world examples, and Azure deep dives, don’t forget to subscribe to System Shogun!