I'm creating app that will run as an automated service with no user interaction to process to connect to a mailbox and process emails (download attachments, move emails to a "processed" folder, etc.). When reading up on the Exchange Web Services (EWS) authentication options, I see that it supports both oAuth and Basic Auth. (see EWS Auth) . The advantages listed for oAuth are that you only risk exposing a temporary auth token for the user, and not the user's credentials. However, AFAIK that only applies to apps that involve user interaction, because in order to connect using oAuth from a service account without any user interaction, you would need to use application credentials (and those app credentials have to be stored in your app config or some other place), and then you have to give the application full access to every user's email account via the Azure AD application registration permissions or else it would require user interaction during the oAuth login process. The basic authentication section of the article makes it sound like this would only be used for demo purposes, and not in production scenarios.
If I were to use oAuth, then I would need to use the OAuth 2.0 client credentials grant type mentioned here: Daemon Auth.
For the scenario when a daemon application needs to call a web API, it’s important to understand a few things. First, user interaction is not possible with a daemon application, which requires the application to have its own identity. An example of a daemon application is a batch job, or an operating system service running in the background. This type of application requests an access token by using its application identity and presenting its Application ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.
In this case isn't Basic Auth a better option, with a dedicated service account for a mailbox, where that account is only used for this mailbox? This seems much safer than using the oAuth authentication route, because if the credentials are compromised, then the attacker only has access to a single service account mailbox, and not the entire company's email via the application client ID and app secret.
Am I missing something?