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

Question

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.

Daniel Vernall · Accepted Answer · 2024-10-07 11:25:10Z

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:

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.

Collectives™ on Stack Overflow

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

1 Answer 1

Comments

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

Comments

Related