Download API call using Incremental Consent fails

Question

Download API call using Incremental Consent fails

Travis Hall 0

We are calling an API from a Blazor app. (.NET 8, Microsoft.NET.Sql.Web, Blazor Server)

The API is called via a client class generated by NSwag from an Open API spec file; therefore, we use .EnableTokenAcquisitionToCallDownstreamApi to modify the HTTP request as it is sent, to add authentication data.

The API call is wrapped in a try/catch, so that we can use ConsentHandler.HandleException to redirect to a login page if the authentication token is not available.

During development on our local machines, this works fine, but we rarely, if ever, call ConsentHandler.HandleException. The environment ensures that we are logged in, and attempt to secure an access token generally succeeds (unless we have done something to make the cached credentials invalid).

However, when deployed into Azure, the application calls the API, the call throws an exception (of type MsalUiRequiredException). The ConsentHandler handles this exception by redirecting to a login page, which may required to the user to log in, then redirects back to the Blazor page, which calls the API again. Again, the API throws an MsalUiRequiredException, the ConsentHandler redirects to login, the login redirects straight back to the application (because by now the user is definitely logged in - after the first login page redirection, if not before), and we loop like this until the browser refuses to call the pages any more.

During startup, AddMicrosoftIdentityWebAuthentiation, EnableTokenAcquisitionToCallDownstreamApi, AddMicrosoftIdentityUI, AddAuthorization, AddMicrosoftIdentityConsentHandler, UseAuthentication, UseAuthorization, and MapBlazorHub are all being called, in the correct order as far as we can tell. (Missing some parts of this seems to be the common reason that a redirect loop like this occurs.)

We are also able to call the API successfully (using different endpoints from the one that is currently causing us the most problems) but only as long as we store the response to the API call using PersistentComponentState. This is only a workaround for some cases, because the results of some of our API calls are too large to store in PersistentComponentState. However, it does tell us that our API can be called correctly in some circumstances. We do not know why this fixes the problem in these cases. When this workaround is in use, we do see the redirection to the login page occur, but only once, with the API call being successfully after being redirected back to the Blazor page. If the page is refreshed, it will go through the redirection again, but only for that one loop.

Travis Hall 0 Reputation points

2025-08-27T01:51:30.8466667+00:00
On the second and subsequent attempts to call the API (the first results in using the ConsentHandler to handle the exception, and a legitimate pass through the authentication system to confirm incremental consent) calling the API results in this exception (with a little proprietary code cut out of the call stack):

Microsoft.Identity.Web.MicrosoftIdentityWebChallengeUserException: IDW10502: An MsalUiRequiredException was thrown due to a challenge for the user. See https://aka.ms/ms-id-web/ca_incremental-consent.

---> MSAL.NetCore.4.74.1.0.MsalUiRequiredException:

ErrorCode: user_null

Microsoft.Identity.Client.MsalUiRequiredException: No account or login hint was passed to the AcquireTokenSilent call.

at Microsoft.Identity.Client.Internal.Requests.Silent.SilentRequest.ExecuteAsync(CancellationToken cancellationToken)

at Microsoft.Identity.Client.Internal.Requests.RequestBase.<>c__DisplayClass11_1.<<RunAsync>b__1>d.MoveNext()

--- End of stack trace from previous location ---

at Microsoft.Identity.Client.Utils.StopwatchService.MeasureCodeBlockAsync(Func`1 codeBlock)

at Microsoft.Identity.Client.Internal.Requests.RequestBase.RunAsync(CancellationToken cancellationToken)

at Microsoft.Identity.Client.ApiConfig.Executors.ClientApplicationBaseExecutor.ExecuteAsync(AcquireTokenCommonParameters commonParameters, AcquireTokenSilentParameters silentParameters, CancellationToken cancellationToken)

at Microsoft.Identity.Web.TokenAcquisition.GetAuthenticationResultForWebAppWithAccountFromCacheAsync(IConfidentialClientApplication application, ClaimsPrincipal claimsPrincipal, IEnumerable`1 scopes, String tenantId, MergedOptions mergedOptions, String userFlow, TokenAcquisitionOptions tokenAcquisitionOptions)

at Microsoft.Identity.Web.TokenAcquisition.GetAuthenticationResultForUserAsync(IEnumerable`1 scopes, String authenticationScheme, String tenantId, String userFlow, ClaimsPrincipal user, TokenAcquisitionOptions tokenAcquisitionOptions)

StatusCode: 0 ResponseBody: Headers:

--- End of inner exception stack trace ---

at Microsoft.Identity.Web.TokenAcquisition.GetAuthenticationResultForUserAsync(IEnumerable`1 scopes, String authenticationScheme, String tenantId, String userFlow, ClaimsPrincipal user, TokenAcquisitionOptions tokenAcquisitionOptions)

at Microsoft.Identity.Web.MicrosoftIdentityUserAuthenticationMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)

at Microsoft.Extensions.Http.Logging.LoggingScopeHttpMessageHandler.<SendCoreAsync>g__Core|5_0(HttpRequestMessage request, Boolean useAsync, CancellationToken cancellationToken)

at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken)

at <our API client code>

at <our Blazor page code>

Inner exception: MSAL.NetCore.4.74.1.0.MsalUiRequiredException: ErrorCode: user_null

Microsoft.Identity.Client.MsalUiRequiredException: No account or login hint was passed to the AcquireTokenSilent call.

at Microsoft.Identity.Client.Internal.Requests.Silent.SilentRequest.ExecuteAsync(CancellationToken cancellationToken)

at Microsoft.Identity.Client.Internal.Requests.RequestBase.<>c__DisplayClass11_1.<<RunAsync>b__1>d.MoveNext()

--- End of stack trace from previous location ---

at Microsoft.Identity.Client.Utils.StopwatchService.MeasureCodeBlockAsync(Func`1 codeBlock)

at Microsoft.Identity.Client.Internal.Requests.RequestBase.RunAsync(CancellationToken cancellationToken)

at Microsoft.Identity.Client.ApiConfig.Executors.ClientApplicationBaseExecutor.ExecuteAsync(AcquireTokenCommonParameters commonParameters, AcquireTokenSilentParameters silentParameters, CancellationToken cancellationToken)

at Microsoft.Identity.Web.TokenAcquisition.GetAuthenticationResultForWebAppWithAccountFromCacheAsync(IConfidentialClientApplication application, ClaimsPrincipal claimsPrincipal, IEnumerable`1 scopes, String tenantId, MergedOptions mergedOptions, String userFlow, TokenAcquisitionOptions tokenAcquisitionOptions)

at Microsoft.Identity.Web.TokenAcquisition.GetAuthenticationResultForUserAsync(IEnumerable`1 scopes, String authenticationScheme, String tenantId, String userFlow, ClaimsPrincipal user, TokenAcquisitionOptions tokenAcquisitionOptions)

StatusCode: 0 ResponseBody: Headers:

I have read through much of the source code for the functions referenced in the call stack. This exception will occur if the account parameter is not passed to GetAuthenticationResultForWebAppWithAccountFromCacheAsync, but as far as I have been able to determine, the account identifier is found within the claims principal of the logged-in user. I can get this data from our own code, and can even get an access token by calling GetAuthenticationResultForUserAsync from our code, but this same call fails when done by the MicrosoftIdentityUserAuthenticationMessageHandler instance. I have tried to replicate the failure by making calls with parameters as similar as I can to what MicrosoftIdentityUserAuthenticationMessageHandler passes, but I have not been able to find the crucial difference.
Vimal Lalani 500 Reputation points Microsoft External Staff Moderator

2025-08-28T12:03:57.88+00:00
Hi Travis Hall

Thank you for posting your question.

The redirect loop with MsalUiRequiredException is usually caused by token caching differences between local development and Azure.

Why it works locally – On your development machine, the in-memory token cache remains alive for the lifetime of the process, so once a token is acquired it can be reused for subsequent API calls.

Why it fails in Azure (even on a single instance) – In Azure App Service, the application pool can recycle, restart, or unload the cache more aggressively than on a local dev machine. Since the default token cache is in-memory, tokens may not persist between requests reliably. This makes each API call appear as if there is no valid token, causing repeated MsalUiRequiredException and redirect loops.

Fix: Persist the token cache – Configure a persistent cache (SQL or Redis) so tokens survive app restarts and across requests:
services.AddMicrosoftIdentityWebAppAuthentication(Configuration) .EnableTokenAcquisitionToCallDownstreamApi() .AddDistributedTokenCaches();

Scopes and consent – Ensure the downstream API scopes are defined in Azure AD and admin consent is granted. Missing consent can also cause repeated login challenges.

With persistent caching, the redirect loop should stop. Locally it works fine because the process lifetime is stable, but in Azure you need persistent token storage to achieve the same behavior, even if you’re only running a single instance.
Travis Hall 0 Reputation points

2025-08-29T01:57:39.3+00:00

After some discussion, we have decided to proceed with implementing a persistent token storage. However, I am a little apprehensive about this. I have been able to use some test code to do token retrievals. We are able to consistently retrieve tokens using an ITokenAcquisition directly injected into a page. The token retrieval only fails when it is done by the call from the MicrosoftIdentityUserAuthenticationMessageHandler class. If the problem is that the token does not persist across requests, then we should also see it fail when retrieved directly by the page, at least sometimes. I worry that this is work in an area that we are not well trained in (so will take a while to get right) when really it may not be related to the problem.

Can you think of a reason why a lack of a persistent token cache should affect MicrosoftIdentityUserAuthenticationMessageHandler differently to other code?

Your answer

Vimal Lalani 500 Reputation points Microsoft External Staff Moderator

2025-08-28T12:03:57.88+00:00

Hi Travis Hall

Thank you for posting your question.

The redirect loop with MsalUiRequiredException is usually caused by token caching differences between local development and Azure.

Why it works locally – On your development machine, the in-memory token cache remains alive for the lifetime of the process, so once a token is acquired it can be reused for subsequent API calls.

Why it fails in Azure (even on a single instance) – In Azure App Service, the application pool can recycle, restart, or unload the cache more aggressively than on a local dev machine. Since the default token cache is in-memory, tokens may not persist between requests reliably. This makes each API call appear as if there is no valid token, causing repeated MsalUiRequiredException and redirect loops.

Fix: Persist the token cache – Configure a persistent cache (SQL or Redis) so tokens survive app restarts and across requests:
services.AddMicrosoftIdentityWebAppAuthentication(Configuration) .EnableTokenAcquisitionToCallDownstreamApi() .AddDistributedTokenCaches();

Scopes and consent – Ensure the downstream API scopes are defined in Azure AD and admin consent is granted. Missing consent can also cause repeated login challenges.

With persistent caching, the redirect loop should stop. Locally it works fine because the process lifetime is stable, but in Azure you need persistent token storage to achieve the same behavior, even if you’re only running a single instance.
Travis Hall 0 Reputation points

2025-08-29T01:57:39.3+00:00

After some discussion, we have decided to proceed with implementing a persistent token storage. However, I am a little apprehensive about this. I have been able to use some test code to do token retrievals. We are able to consistently retrieve tokens using an ITokenAcquisition directly injected into a page. The token retrieval only fails when it is done by the call from the MicrosoftIdentityUserAuthenticationMessageHandler class. If the problem is that the token does not persist across requests, then we should also see it fail when retrieved directly by the page, at least sometimes. I worry that this is work in an area that we are not well trained in (so will take a while to get right) when really it may not be related to the problem.

Can you think of a reason why a lack of a persistent token cache should affect MicrosoftIdentityUserAuthenticationMessageHandler differently to other code?

Share via

Download API call using Incremental Consent fails

Your answer