SMTP XOAuth authentication and Microsoft authentication libraries

[CerarP]

Due to the upcoming deprecation of basic authentication our company is looking to move all our products to modern authentication protocols for sending emails but we have some unusual usage scenarios that have me running in circles. I have been through all available documentation multiple times and I'm stuck.

The problem is that we have on premise web applications that are running on multiple client servers and not a central location. This creates a problem when using standard OAuth flows since there is no fixed URL to use as a redirect URI. Because of this I have created a separate API on a fixed URL that will serve as the redirect URI for all clients and instances of our web applications. This breaks the standard usage of MSAL library and I had to go around chasing my tail to even be able to implement something that could possibly work. I have been able to do it using Microsoft.Identity.Client MSAL library but I hit a problem since I need to use the ConfidentialClientApp.AcquireTokenByAuthorizationCode call to redeem the access code obtained after user login but apparently SMTP does not allow confidential clients to login. We need the application to be able to send emails from any account any tenant or personal accounts. I have obtained the access token for a personal account but SMTP rejects it with this error: 535: 5.7.3 Authentication unsuccessful [AM8P251CA0016.EURP251.PROD.OUTLOOK.COM].

If I switch to PublicClientApplication then there is no AcquireTokenByAuthorizationCode method and I can't even use client secret so I'm not even sure how this works in redeeming a code.

I am going by instructions on this page: https://docs.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-i... and it mentions no requirement of a public client application. It states I can use authorization code flow and the documentation on authorization code flow states it can be used by web apps and desktop apps. Well how am I supposed to use it when SMTP won't accept a confidential app and the PublicClientApplication does not have a method to redeem it?

If I drop the authentication library and go for pure REST API call implementation, which application credentials should I use that the acquired tokens will be accepted by the SMTP server?

Also I would like to know if office 365 users still have to disable security defaults and enable STMP Authentication to use SMTP with OAuth 2? This would defeat the whole purpose of migrating to OAuth 2 and the blog about deprecation states that moving to OAuth 2 is the way to prepare your app for this deprecation, but I've seen instructions on SMTP OAuth that state SMTP Authentication still needs to be enabled.

[#2]

I managed to find a solution for personal Microsoft accounts. Sending from those accounts requires these two settings enabled in app registration in Azure:

Advanced settings

Live SDK support

Allow direct integration with the Microsoft account service (login.live.com).
Required for integration with Microsoft account SDKs such as Xbox or Bing Ads​

Allow public client flows

Enable the following mobile and desktop flows:

• No keyboard (Device Code Flow) Learn more

The first one is logical and I had it on from the start, the second one however makes no sense since I am using authorization code flow, but turning it on allows sending over SMTP from personal accounts.

One big catch after all this trouble and a week of trying to figure out how to get around the rigid implementation of authentication libraries and lack of proper documentation:

Sending over SMTP using OAuth 2.0 still requires office 365 users to disable security defaults and enable SMTP Authentication!!!

This makes no sense and is definitely not an improvement on security. Documentation on basic authentication deprecation states that we need to migrate to secure authentication flows but using OAuth on SMTP requires clients to enable basic authentication as well. I know they can be disabled separately by an admin and only XOAUTH left enabled but that is complicated and completely unnecessary. SMTP with XOAuth authentication should be enabled by default. All this does is force us to use Graph API to send emails, which is in no way related to security. If every email provider decided we have to use their APIs to send emails and not a standard protocol, we would need a new developer just for implementing sending emails which should be a trivial matter.

[#3]

1.5 years later I am still waiting for anyone to explain the logic behind this. If we follow the instructions to implement OAUTH2 due to security concerns, why does it still require to enable SMTP Authentication which also enables basic authentication???