AZ-204 ITokenAcquisition Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use ADAL.NET's `AcquireTokenOnBehalfOf` method

  Why it's wrong here

  ADAL.NET (Azure Active Directory Authentication Library for .NET) is a deprecated library. While its `AcquireTokenOnBehalfOf` method technically supports the On-Behalf-Of flow, it is no longer actively maintained and lacks support for newer features and security enhancements. Modern ASP.NET Core applications should leverage MSAL.NET or, more specifically, Microsoft.Identity.Web, which provides a higher-level abstraction and integrates seamlessly with the ASP.NET Core authentication pipeline for robust token acquisition.

• ✓

  Inject `ITokenAcquisition` and call `GetAccessTokenForUserAsync` with the scopes for the downstream API

  Why this is correct

  This is the recommended and most robust approach for an ASP.NET Core Web API to acquire a token for a downstream API using the On-Behalf-Of flow. `ITokenAcquisition` is an interface provided by `Microsoft.Identity.Web`, which simplifies token acquisition by abstracting away the complexities of MSAL.NET. Calling `GetAccessTokenForUserAsync` with the required scopes automatically handles exchanging the incoming user's access token for a new token valid for the specified downstream API, including token caching and refresh.

• ✗

  Use the `Azure.Identity` library with `DefaultAzureCredential` to acquire a token

  Why it's wrong here

  The `Azure.Identity` library, particularly `DefaultAzureCredential`, is designed primarily for authenticating applications or services to Azure resources, often using managed identities, service principals, or developer credentials. It establishes an application's identity, not a user's delegated identity. It does not support the On-Behalf-Of flow, which is necessary to propagate the *user's* identity and permissions from the calling API to a downstream API.

• ✗

  Manually construct an HTTP POST to the Microsoft Entra ID token endpoint with the user access token and client credentials

  Why it's wrong here

  While technically feasible to manually construct an HTTP POST request to the Microsoft Entra ID token endpoint to perform the On-Behalf-Of flow, this approach is highly discouraged. It necessitates manual handling of numerous complexities, including proper request formatting, error handling, token caching, token refresh, and secure storage of client secrets. This significantly increases development effort, introduces potential security vulnerabilities, and makes the application harder to maintain compared to using well-established libraries like Microsoft.Identity.Web.