Announcing OAuth 2.0 support for IMAP and SMTP AUTH protocols in Exchange Online

I’ve read the linked documentation several times now, and as far as I can tell, there’s no way for automated (non-interactive) applications or daemons to access Exchange Online mailboxes using IMAP with OAuth. Or am I missing something? The issue is requesting tokens. The doc suggests that only two OAuth flows - Authorization Code Flow and Device Authorization Grant Flow - are supported by IMAP. Neither of which appears to be suitable for non-interactive auth. The doc also states that “OAuth access to IMAP, POP, SMTP AUTH protocols via OAuth2 client credentials grant flow is not supported” and that is the flow recommended by Microsoft for server to server or non-interactive apps! The suggestion is to use Graph API “if your application needs persistent access to all mailboxes in an tenant”. But we just need individual non-interactive applications to have access to specific mailboxes via IMAP using OAuth. Or can we use any OAuth flow via the MSAL client libraries, including ROPC or Windows Integrated Authentication that should support non-interactive auth? We have many non-interactive apps that use IMAP to programmatically access EXO mailboxes. If not, how are these apps supposed to migrate to OAuth?

stukeyExactly my question also. 

Jared Pickerell - we haven't said when SMTP AUTH will require OAuth. It's going to take much longer, we know that. 

With this (April 30th ’20) release of OAuth2 support for IMAP and SMTP, Sivaprakash-MSFT commented on Stackoverflow: “IMAP, SMTP scopes are targeted for Exchange resource and not Graph” and “... we will only allow Exchange resource URLs to work and don’t have plans to enable Graph resource URLs”. But under AAD API permissions, SMTP.Send only appears as selectable when the Microsoft Graph API is selected. If I select the Exchange API (under Supported legacy APIs or via Enterprise apps), there is no selectable SMTP.Send or IMAP.AccessAsUser.All. So if my app uses a scope of outlook.office365.com/SMTP.Send, or outlook.com/SMTP.Send there isn't a matching permission in AD except under graph.microsoft.com/ (apparently the wrong API…).

I gather from Stackoverflow posts that there is confusion over:

- the URL prefix (e.g. https://outlook.office.com/) of a requested scope such as https://outlook.office.com/SMTP.Send as specified in an app

- the API selected in AAD to allow that scope (e.g. Microsoft Graph or Exchange)

Perhaps someone in the Exchange Team could clarify.

Tnx

We very recently added client credential flow for IMAP to the public roadmap. We're working on it. Roadmap Item 70577 

The_Exchange_Team, thank you for the update! I'll be using IMAP and SMTP to implement some functionality and this is definitely helpful.

I tried the steps from the provided instruction, but it didn't work. I've submitted my finding to the StackOverflow question, can someone from your team have a look at this?

I'm afraid of how many multi-function copiers and legacy applications this is going to take down. A very real and major concern once OAuth 2 is the only way to send email through the Exchange Online SMTP servers! 

MSAL libraries have been announced for:

- .NET (unsurprisingly)

- JavaScript and TypeScript superset framworks

- Android

- iOS and MacOS

- Java (for Windows, macOS and Linux)

- Python (Windows, macOS, and Linux)

But lack of PHP support for SMTP AUTH with Oauth2 will have a devastating impact on the zillions of backend apps that currently use Basic Authentication.

As an example, the hugely popular PHPMailer used, I guess, on every Linux / Apache server in the universe supports Oauth2 for access to Gmail, Yahoo and the older MSFT consumer mail platforms and (with some difficulty) for the Azure AD for developers (v1.0) endpoint but not for the MSFT identity platform (v2.0) endpoint: when pointed at V2.0 in order to use SMTP AUTH for outbound access to O365 Exchange Online, it will fail, even with the obvious changes to ‘authorise’ and ‘token’ endpoint URLs and to scopes (aka permissions).

And SMTP AUTH support has only and understandably been announced for the V2.0 endpoint so there is no way to regress via V1.0, even as a stopgap.

Deprecating Basic Authentication is a sensible move, but Oauth2 is FAR more complex to work with, and since MSFT wants everyone to be on O365 (and why not?), MSAL support for PHP would be appreciated. All the backend PHP apps that need to use Oauth2 to access O365 services will need rework, and it seems sensible integrate MSAL instead of direct calls to the V2.0 endpoint.

Max_Decomplexity are you updating your refresh token every time you use one to retrieve a new token? I've seen similar behavior when the client app uses a refresh token to request a new access token, but doesn't update the first refresh token with the one returned as part of a successful toke response (See Microsoft identity platform and OAuth 2.0 authorization code flow - Microsoft identity platform | Microsoft Docs. From the documentation " You should replace the old refresh token with this newly acquired refresh token to ensure your refresh tokens remain valid for as long as possible."

mike_soe I believe this linked article/section is the answer for your question: https://docs.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth#register-service-principals-in-exchange

TL;DR to summarize here is that you need to manually bring your Service Principal(s) (from your apps setup in AAD) into EXO via New-ServicePrincipal (EXO cmdlet) and then they're available in EXO to be granted FullAccess to whichever mailboxes you decide.