MsalProvider uses unknown redirect URI, authentication fails

[jasonjoh]

Describe the bug

When using the MsalProvider as documented and as in the sample, auth fails with AADSTS50011.

Request Id: 5e464c00-92a4-4a14-a5e6-f6c807527900 
Correlation Id: 70fa290d-da9e-4a48-ac59-98da60a73410 
Timestamp: 2022-04-29T14:51:55Z 
Message: AADSTS50011: The redirect URI 'ms-appx-web://Microsoft.AAD.BrokerPlugin/S-1-15-2-3827128064-569582487-4294593430-3382639814-4294318972-3676523608-2734131615' specified in the request does not match the redirect URIs configured for the application '3892d014-2554-4df7-a10b-9f1e5c0742e7'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.

• Is this bug a regression in the toolkit? If so, what toolkit version did you last see it work:

Steps to Reproduce

Steps to reproduce the behavior:

1. Register an app in Azure AD using the redirect URI https://login.microsoftonline.com/common/oauth2/nativeclient.

2. Configure your provider.

   string[] scopes = new string[] { "User.Read" };
   ProviderManager.Instance.GlobalProvider = 
       new MsalProvider("CLIENT_ID", scopes);

3. Try to login with the LoginButton.

Expected behavior

Should login

Environment

NuGet Package(s): 
CommunityToolkit.Authentication.Msal 7.1.1
CommunityToolkit.Graph.Uwp 7.1.1

Windows 11 Build Number: (10.0; Build 22000)

App min and target version: Windows 10, version 2104 (10.0; Build 20348), Target Windows 11 (10.0; Build 22000)

Device form factor:
- [x] Desktop
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT

Visual Studio 
- [ ] 2017 (version: )
- [ ] 2019 (version: ) 
- [ ] 2019 Preview (version: )
- [x] 2022 (version: 17.1.6)

Hello jasonjoh, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

[michael-hawker]

@jasonjoh this isn't an undocumented url, it's generated from calling this public API in the web authentication broker.

As used here:

Graph-Controls/CommunityToolkit.Authentication.Uwp/WindowsProvider.cs

Line 49 in 15513b1

public static string RedirectUri => string.Format("ms-appx-web://Microsoft.AAD.BrokerPlugIn/{0}", WebAuthenticationBroker.GetCurrentApplicationCallbackUri().Host.ToUpper());

Did you try the steps in the url provided by the error message? https://aka.ms/redirectUriMismatchError

@shweaver-MSFT is this something we should call out in the docs, this url just needs to be registered in Azure right? As the default one is only recommended for embedded browsers?

[shweaver-MSFT]

If you don't mind, @jasonjoh, try out what @michael-hawker suggested. I'm curious if that works for you. The guidance in the README/docs certainly doesn't tell you to do this for the MsalProvider, so I can see why you are confused. When I wrote the docs it didn't seem to be a requirement to use that custom redirect URI, only for the WindowsProvider. But perhaps something has changed since then.

[shweaver-MSFT]

Oh actually... looking at this closer, I can see that you aren't specifying a redirect uri when you create the MsalProvider instance:

string[] scopes = new string[] { "User.Read" };
ProviderManager.Instance.GlobalProvider = 
    new MsalProvider("CLIENT_ID", scopes);

Somewhere in MsalProvider, if you don't provide a redirect uri it will attempt to figure it out for you. I think the part you missed is actually passing that redirect uri into the constructor:

string[] scopes = new string[] { "User.Read" };
string redirectUri = "https://login.microsoftonline.com/common/oauth2/nativeclient";
ProviderManager.Instance.GlobalProvider = 
    new MsalProvider("CLIENT_ID", scopes, redirectUri);

I didn't think this was necessary, but I can tell by the error message you showed that Msal is picking a very different redirect uri than what the docs recommend. The other option is to go the other way, and add the url it listed in the error message back into your azure config.