How to use "Modern auth" with MSAL.NET and personal Microsoft accounts

We're migrating our desktop software from using SMTP auth for email, to using modern auth. The application requests IMAP and SMTP permissions for an integrated email client.

We already have organization-based auth working using MSAL.NET, but even after configuring our application in Azure Portal, personal accounts fail to log in with an exception message which doesn't help.

Here is the configuration on portal.azure.com:

and the API permissions:

Here is the creation code using MSAL.NET (in VB)

Dim brokerOptions As New BrokerOptions(BrokerOptions.OperatingSystems.Windows)

clientApp = PublicClientApplicationBuilder _
    .Create(ClientID) _
    .WithWindowsDesktopFeatures(brokerOptions) _
    .WithAuthority(AadAuthorityAudience.AzureAdAndPersonalMicrosoftAccount) _
    .Build()

And then when we need interactive login, we call this:

ar = Await ClientApp.AcquireTokenInteractive(Scopes) _
    .WithAccount(firstAccount) _
    .WithParentActivityOrWindow(handle) _
    .WithPrompt(Prompt.SelectAccount) _
    .ExecuteAsync()

When we use an organization Microsoft 365 account, it works fine. But when we try to log in with a personal outlook.com/live.com/hotmail.com account it fails with the following error, before asking for the password/MFA:

WAM Error  
 Error Code: 2156265473 
 Error Message: ApiContractViolation 
 WAM Error Message: (pii) 
 Internal Error Code: 557973635 
 Possible causes: 
- Invalid redirect uri - ensure you have configured the following url in the application registration in Azure Portal: ms-appx-web://microsoft.aad.brokerplugin/<OUR APP CLIENT ID>

Note that the above error says the "possible" cause may be an invalid redirect uri. This is not the real reason because the redirect uri was copy/pasted into the app configuration. Also, it works fine for organization logins, so the redirect uri can't be the issue.

I'm not sure what else could be the problem.

We finally managed to resolve the problem. It appears to be entirely undocumented as we couldn't find any information about it. Maybe it is documented somewhere but because Microsoft keeping renaming their services it is hell to find any information.

The issue appears to be caused by mismatched scopes.

When configuring the Microsoft Entra ID application, SMTP permissions/scopes are now listed under Microsoft Graph, (as shown in my question screenshot), and they have the following format: https://graph.microsoft.com/<Permission>. E.g.,

These have been renamed from the previous, https://outlook.office365.com/<Permission>.

Either of these work fine for organizational Microsoft 365 accounts. But if you use scopes of either of the above formats for personal accounts, then although you can get an Access Token successfully, when you then try to authenticate the client using the access token, it fails with an authentication error response (535, 5.7.3).

After following various Microsoft support/community threads:

• https://answers.microsoft.com/en-us/msoffice/forum/all/535-573-authentication-unsuccessful/cd915151-ae89-4505-8ad3-29680554e710?page=5

• https://techcommunity.microsoft.com/t5/outlook/smtp-xoauth-suddenly-failing-for-outlook-personal-with-535-5-7-3/m-p/3734392/page/2

• https://techcommunity.microsoft.com/t5/security-compliance-and-identity/smtp-xoauth-suddenly-failing-for-outlook-personal-with-535-5-7-3/m-p/3738000

I eventually found that someone managed to get it to work with...entirely different scope domains.

The scopes which currently work with both Organization and Personal Microsoft accounts for IMAP and SMTP appear to be:

• https://outlook.office.com/SMTP.Send
• https://outlook.office.com/IMAP.AccessAsUser.All
• https://outlook.office.com/User.Read
• offline_access

If someone knows where the docs say anything about this it would be great to know.