Incremental Scope Consent asks for complete re-login

[michael-hawker]

Describe the bug

When making a call in the app which requires a new permission, one not initially requested at login. The MSAL dialog pops-up and asks for credentials again, instead of recognizing the already logged-in user.

Need to investigate if new MSAL 4.4.0 release we need to pick-up exhibits this same behavior.

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to App.xaml, enter new ClientId (or maybe uninstall sample app?), remove People.Read permission
2. Click on Sign-in, Login, and Consent
3. Search for a person in the PeoplePicker
4. See auth dialog pop-up again, but at login screen instead of permissions screen

Expected behavior

User should be redirected directly to permissions screen as already logged in.

[michael-hawker]

Using latest Microsoft.Graph.Auth with MSAL 4.14 now and noticing similar issue where if I've logged in and then close app, change the scope, and try and run app again, it gets caught in a login-loop asking me for login info again and just looping.

Microsoft.Identity.Client.MsalUiRequiredException
MsalThrottledUiRequiredException
Microsoft.Graph.Auth.AuthenticationException

[shweaver-MSFT]

This is a little less relevant now, and I'll explain why:

The Graph requests are all handled in the CommunityToolkit.Graph package and use the Beta Graph SDK to build the requests and execute them. Previously, we had done this work using a special method called WithScopes from the SDK to request additional scopes on the fly. This creates the incremental consent experience as users consume new components for the first time, they will consent and be good to go.

However, the WithScopes method is ONLY available in the Beta Graph SDK, so when we switched to use the stable release, I had to comment out those WithScopes methods, which effectively disables the incremental consent support in the controls. There is also a new "scopes" parameter on IProvider.GetTokenAsync, so devs can request additional scopes manually as an immediate workaround. But this is not what we want long term, so since we are only releasing the auth helpers initially, hopefully we can find a solution by the time we need to release the other helpers and controls.

Then, based on whatever the current state of things is, we can reevaluate whether this bug still exists or not.

[shweaver-MSFT]

WithScopes is back, so this needs testing to see if the issue still exists or not.

[shweaver-MSFT]

I re-added the WithScopes calls and tested to see if the incremental consent would work and it consistently throws 403 - Forbidden when calling for scopes that are not already consented to, and no consent dialogue is shown. When this exception fires, it tells me that the globally configured authentication provider does not support incremental consent, and the user will need to be prompted for consent forcefully to gain access. We are really relying on the OS and MSAL library to handle these cases because we don't get a lot of control over the consent experience.

I don't expect WindowsProvider to work, because the underlying APIs do not yet support incremental consent, but it should work for the MsalProvider. Unfortunately, the MsalProvider will not show the consent dialogue when adding additional default scopes between logins and continues to force a complete re-login for the new scopes requested.

The login-loop issue appears to be resolved though, so that's a little bit of good news. Signing in will fix the issue, but the SSO-like experience breaks down because we don't prompt for consent during a silent login attempt. The user will have to login again manually.

Takeaway: We need to figure out how to properly support incremental consent via MSAL for .NET.

To be continued...