Office 365 - Handle the deactivation of IMAP basic auth with noninteractive service-applications

user_4202085 0
Viewed 1168

We have a self-developed, non-interactive service application for many different customers on premise. Untill now, this application retrieves emails from a customer's mailbox via o365 IMAP (basic authentication) and also sends emails via o365 SMTP (basic authentication).

In October 2022, Basic Authentication for IMAP, EWS, POP3 etc. is to be deactivated. For non-interactive applications, it is recommended to switch to MS Graph. (https://techcommunity.microsoft.com/t5/exchange-team-blog/announcing-oauth-2-0-support-for-imap-and-smtp-auth-protocols-in/ba-p/1330432).

The prerequisite for this, as far as I have been able to reproduce so far, is that the customer creates an app registration in the Azure portal that assigns the Mail.Read and Mail.Send permissions, create client-secret and redirect-URL., etc. A policy must then be created, which only authorizes this app ID to a specific mailbox security group (which must also be created in o365), so that the app cannot access all mailboxes (https://docs.microsoft.com/en-us/graph/auth-limit-mailbox-access).

Unfortunately, this are many steps in total, which are also relatively complex, which we can not expect of our customers. Some of these customers manage their IT environment themselves, although they are not very comfortable with it. These customers will have trouble completing these steps.

Now my question is whether there isn't another, simpler solution to the problem, or whether the steps mentioned can perhaps be shortened or automated?

Thanks and greetings Boris

office365 microsoft-graph-api oauth-2.0 imap basic-authentication
1 Answers

The prerequisite for this, as far as I have been able to reproduce so far, is that the customer creates an app registration in the Azure portal that assigns the Mail.Read and Mail.Send permissions, create client-secret and redirect-URL., etc. A policy must then be created, which only authorizes this app ID to a specific mailbox security group (which must also be created in o365), so that the app cannot access all mailboxes (https://docs.microsoft.com/en-us/graph/auth-limit-mailbox-access).

Oauth has a number of different flows that you can use depending on the type of application your creating. The one your talking about is the client credentials flow which is the best and most secure approach for an application https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow you can automate the setup process using PowerShell there's a good sample https://docs.microsoft.com/en-us/samples/azure-samples/ms-identity-aspnet-daemon-webapp/build-multi-tenant-daemon-aad/.

The other non-interactive flow you could use is ROPC https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc which is more like your using now where you have explicit credentials you use and the permissions assigned to those credentials dictate the level of access. This still require an Azure application registration but you can use a Multi Tenant registration (as long as you become a verified publisher) and all the customer needs to do is grant your app consent in their tenant (one time). ROPC because you have explicit credentials is less secure (and generally not recommended because of this).

user_10809230
Related