You have a single-page application (SPA) that calls an Azure App Service Web API (API A). API A must call a downstream API (API B) on behalf of the signed-in user and enforce the user’s permissions in API B. API B already exposes scopes in its app registration. You need to preserve the user’s identity when calling API B and avoid granting API A broad application permissions. Which two actions should you perform?

To preserve the user's identity and permissions when API A calls API B, the On-Behalf-Of (OBO) flow is required. The first correct action, using MSAL's AcquireTokenOnBehalfOf with the incoming bearer token as a UserAssertion, implements this flow. This exchanges the user's token for a new token scoped for API B, maintaining the user's identity. The second correct action, adding API B as a delegated permission to API A's app registration and granting admin consent, is necessary because API A needs permission to call API B on behalf of the user. Without this, the OBO flow would fail. Using the client credentials flow (incorrect option) would mean API A calls API B using its own identity, losing the original user's context and permissions. Configuring API B to use application roles instead of scopes (incorrect option) doesn't address the need to forward the user's identity and delegated permissions; scopes are the standard way to define granular permissions for APIs.