Chapter 1 of 6
Module scope#
What we will do#
Objective. Give a downstream API the signed-in user's identity when a trusted middle tier calls it on the user's behalf.
Configure an existing trusted Python middle tier to exchange a signed-in user's token for a delegated token for an existing protected API: record the approved client, middle tier, downstream audience, delegated scope, and consent boundary; add only the approved delegated permissions; validate the inbound assertion; and use a protected Azure Key Vault certificate for the OAuth 2.0 on-behalf-of (OBO) exchange. Then confirm that a permitted user succeeds and that a user without downstream resource authority is denied.
Why it matters#
Problem. A workload identity gives the middle tier the same application authority for every request. It does not fit a downstream resource whose access must change with the signed-in user.
Solution. OBO carries that user context across the middle tier without forwarding the original bearer token.
The permitted-user check confirms that Microsoft Entra ID accepts the delegated trust chain. The denied-user check confirms that the downstream API still enforces its user-specific resource rules.
Boundaries#
The module changes exact delegated permissions and consent, the middle-tier OBO implementation, and its payload-free diagnostics. It works with the existing applications and downstream authorization model.
The certificate remains in Azure Key Vault and reaches the approved runtime only through its protected certificate integration. This repository stores references, never private keys, bearer tokens, tenant values, endpoints, or user data.
Use this module only when an existing client, confidential middle tier, and protected downstream API already require per-user authorization, and record signed-in user OBO as the authority decision before starting. If the operation should run with one workload identity regardless of who started it, use managed identity instead. That path is outside this module.
Module preparation
Who should join
- Application and API engineers
- Microsoft Entra identity and application security engineers
- Owners of APIs that authorize each signed-in user
What you need
- An approved nonproduction tenant has existing Microsoft Entra application registrations for the client, confidential Python middle tier, and protected downstream API.
- The middle tier has its own API audience and User
access_as_userdelegated scope; the downstream API has its own API audience and narrow delegated read scope. - An exportable Azure Key Vault certificate is approved for middle-tier client authentication and can be exposed as a protected PFX through the approved runtime integration.
- A named customer identity owner can approve the exact client-to-middle-tier and middle-tier-to-downstream delegated permissions and consent.
- The customer has chosen signed-in user OBO because the downstream API must authorize each user; application-only managed identity is for shared or background work and is outside this module.
- One permitted user and one user without downstream resource authority can run the delivery checks.