MsalUiRequiredException from AuthorizeForScopesAttribute

[creativebrother]

Hi, I just notice that my server windows application log is full of the above errors which the user will not see. Could we somehow eat the exceptions within the above exception filter instead so the server application log is cleaner?

Thanks,

[jmprieur]

@creativebrother
I see you point.
Note that the logs can also indicate, in some cases, that you would not need the incremental consent if you specified the scopes in EnableTokenAcquisitionToCallDownstreamApi, so there would still be value in surfacing them in that cases

Is this your case? Or is yours more a claims challenge? or the fact that the token is no longer in the in-memory cache whereas its in the session cookie?

[creativebrother]

incremental consent with AuthorizeForScopesAttribute is not feasible in my case when I have some viewcomponent call which need the token and it seemed that it is not covered by that attribute. So I end up using the EnableTokenAcquisitionToCallDownstreamApi(initialScopes) and admin consent to cover them all.

In the previous version of the Identity.Web prior 1.8.0, I also need to add another safeguard (via middleware) to check whether the token is still in cache (since it will be removed when it is expired, and meanwhile the cookie may still valid which cause the MSALUIRequired Exception to throw). I noticed in 1.8.1, even though the token cache entry is deleted, the L1 seems still working, but in the load balanced farms, it will still have issues.

[creativebrother]

What I meant for the L1, L2 cache issue above is that in the case of valid authentication cookie while the token expired and deleted, I have not find a good way to catch those MsalUIRequired exception with viewcomponent of the asp.net core and trigger re-authenctication. So I endup using the custom middleware to test the token and trigger a new challenge.

            var isauthenticated = context.User?.Identity?.IsAuthenticated ?? false;
            var hasaccesstoken = true;
            if (isauthenticated && context.Request.Path.Value != "/MicrosoftIdentity/Account/Signin")
            {
                try
                {
                    var accessToken = await _tokenAcquisition.GetAccessTokenForUserAsync(new[] { 
                    "https://graph.microsoft.com/Mail.Read" });
                }
                catch (Exception exception)
                {
                    var msaluiex = FindMsalUiRequiredExceptionIfAny(exception);

                    hasaccesstoken = msaluiex == null;
                }
            }
            if (isauthenticated && !hasaccesstoken && context.Request.Path.Value 
                !="/MicrosoftIdentity/Account/Signin")
            {
                context.Response.Redirect("/MicrosoftIdentity/Account/Signin");
            }
            else
            {
                await _next(context);                
            }

[creativebrother]

I now understand that the log can be served as a surfacing tool to see all the places that the exceptions are happening and use the initial scopes to cover them (in my case I have to use admin consent because there are a bit too long to popup the consent screen during login). For the purpose of cleaning the msaluirequired errors in the event log, I may change the log level to avoid that for that specific module.
Thanks for clarifying that.