Our application was updated late last year to support Oauth2 for obtaining (via IMAP) and sending (via SMTP) emails on behalf of outlook.com consumer accounts. (Edit: See responses below if experiencing the problem with Microsoft 365 accounts.)
We have both SAS and premise based deployments which were tested as able to send and receive in December 2022, but are now getting 5.7.3 Authentication unsuccessful when attempting to authenticate with the SMTP server. IMAP continues to work just fine.
Here's an example flow:
User is prompted for authorization:
https://login.microsoftonline.com:443/common/oauth2/v2.0/authorize?prompt=consent&response_type=code&state=59b234bd-fdc0-4905-8e57-bbd4b091cf4f&scope=https%3a%2f%2foutlook.office.com%2fSMTP.Send+https%3a%2f%2foutlook.office.com%2fIMAP.AccessAsUser.All+offline_access&access_type=offline&redirect_uri=http%3a%2f%2flocalhost%3a68%2fEmail%2foauth%2f&login_hint={outlook.com email address}&client_id={our registered + verified clientid}
The scopes are
https://outlook.office.com/SMTP.Send
https://outlook.office.com/IMAP.AccessAsUser.All
offline_access
We receive our callback after the user logs in and provides permission.
?code={access_code}&state=59b234bd-fdc0-4905-8e57-bbd4b091cf4f
Then call to exchange the access code for a token...
https://login.microsoftonline.com/common/oauth2/v2.0/token
client_id={client id}&code={access code}&redirect_uri=http%3a%2f%2flocalhost%3a68%2fEmail%2foauth%2f&grant_type=authorization_code
...and receive our access and refresh tokens in response.
{
"token_type": "Bearer",
"scope": "https://outlook.office.com/SMTP.Send https://outlook.office.com/IMAP.AccessAsUser.All",
"expires_in": "3600",
"ext_expires_in": "3600",
"access_token": "{access_token}",
"refresh_token": "{refresh_token}"
}
MailKit is then used to connect and authenticate to the IMAP server outlook.office365.com. No errors. New mail can be read from the user's inbox.
But attempting to authenticate the SMTP (again using MailKit) client results in "535: 5.7.3 Authentication unsuccessful"
The same SaSLMechanismOAuth2 with the account's email address and current access token are used for both.
Other notes:
- Our Application ID / Client ID on Azure AD has been verified.
- I haven't been able to identify any changes in our methodology since this was tested as working in December.
- I tried some variations on the scope, such as including https://graph.microsoft.com/SMTP.Send but this made no difference.
- I'd prefer not to use any separate Graph APIs for sending email as our product must communicate with other SMTP servers/providers
- I'm aware that SMTP Authentication can still be used, but since we can no longer use basic authentication for IMAP or POP, I'd prefer not to store the user's credentials at all.
- I added additional API permissions to our clientId but again no effect (screenshot below)
