Examkin

Question

Difficulty: HardMicrosoft Identity Platform Authentication

You are developing an ASP.NET Core Web API that runs in an autoscaling Azure App Service plan. The Web API authenticates users using the Microsoft Identity Platform. It must make downstream calls to Microsoft Graph on behalf of the signed-in user by using the OAuth 2.0 On-Behalf-Of (OBO) flow.

During load testing, you observe that downstream calls experience intermittent latency and fail with HTTP 429 (Too Many Requests) errors from Microsoft Entra ID. You determine that because the App Service scales out to multiple instances, each instance maintains a separate in-memory token cache, resulting in frequent, redundant token exchange requests to Microsoft Entra ID.

You need to resolve the performance issue and prevent rate-limiting while maintaining the signed-in user's context for Microsoft Graph calls.

Which of the following configuration changes should you implement?

  1. A
    Enable a system-assigned managed identity on the Azure App Service host to bypass user-delegated token acquisition for Microsoft Graph.
  2. B
    Generate a Shared Access Signature (SAS) token with appropriate delegated permissions and pass it in the authorization header of downstream requests.
  3. Configure a distributed cache (such as Azure Cache for Redis) and register it in the application startup using the AddDistributedTokenCaches method.Answer
  4. D
    Write custom middleware to extract, encrypt, and store the user's delegated access tokens inside Azure Key Vault Secrets.

Answer

Configure a distributed cache (such as Azure Cache for Redis) and register it in the application startup using the AddDistributedTokenCaches method.
Configuring a distributed cache (such as Azure Cache for Redis) and registering it using the `AddDistributedTokenCaches` method is correct because it shares the token cache across all instances of the scaled-out App Service. When one instance exchanges the user's incoming assertion for a downstream token using the On-Behalf-Of flow, the acquired token is stored in the shared distributed cache. Subsequent requests from the same user handled by other instances will read the token directly from the distributed cache, preventing redundant token exchange calls to Microsoft Entra ID and avoiding HTTP 429 throttling.

Step-by-Step Solution

1
Analyze the token caching behavior in a multi-instance Web API environment.
Realized that default in-memory token caching is limited to individual hosts, leading to cold caches on new scale-out instances and resulting in redundant OAuth 2.0 OBO requests to Microsoft Entra ID.
To identify why rate-limiting and performance degradation are occurring under load.
2
Select a shared token cache strategy that spans across all application instances.
Chose distributed token caching utilizing an external store such as Azure Cache for Redis or SQL Server.
A shared cache ensures that once an access token is acquired for a user, any scaled-out instance can access and reuse it, avoiding redundant OBO token exchanges.
3
Register the distributed token cache in the dependency injection container of the ASP.NET Core API.
Added `AddDistributedTokenCaches` to the authentication builder chain in the application's startup file.
This configures the Microsoft.Identity.Web library to write and read tokens from the registered `IDistributedCache` provider instead of the default in-memory cache.

Key Concept

Distributed Token Cache Serialization in MSAL / Microsoft.Identity.Web
Estimated Time:2m 30s
Rate this question

Topics

Microsoft Identity Platform Authentication

More questions from this topic