Currently, when sending emails through Office 365 from Cherwell, you have a few connection options. How you set up your connection in Cherwell will determine how the email is sent through Microsoft’s Online Exchange system. The 3 available methods include:
Basic Authentication. Although Microsoft retired Basic Auth for receiving emails, there are no plans to retired it for sending emails (SMTP). However, Basic Auth is the least secure method of sending emails, so it is no longer recommended for Cherwell users to send emails via Basic Auth
OAuth2 and Exchange Web Services (EWS). Modern Auth is the common term used by Cherwell to connect to EWS more securely than with the original Basic Auth. This connection type was introduced in Cherwell 10.1 and you must be on that version to support OAuth2 connections to EWS. However, EWS is ALSO being retired! EWS has been around since 2007 and Microsoft is no longer actively investing in it any more. So, even though Cherwell was rather late to the party in supporting OAuth2 with EWS, be prepared to move on quickly from this mode of connectivity. There is currently no End Of Support date (EOS) for EWS.
Graph API connectivity. Microsoft is switching the majority of it’s Microsoft 365 applications to the Graph API for any connectivity. Currently, the Graph API supports sending and receiving emails in the M365 environment. Cherwell release 2022.3 finally supports sending and receiving emails using the Graph API connector.
Main differences between the EWS and Graph API connectors:
Security
Microsoft Graph has stricter security and governance policies with OAuth and granular scoping to limit data access in a mailbox as opposed to the “all or none” access model in EWS.
REST efficiency
Microsoft Graph APIs are REST-based, where EWS APIs are SOAP-based. The advantage of using REST-based protocols include faster JSON serialization and lower network usage.
Deeper dive into Permissions differences:
EWS and Microsoft Graph offer two types of permissions: delegated and application. Delegated permissions are in the context of an authenticated user. Application permissions are granted to an application that does not act on a user’s behalf.
With EWS, an application has access to everything that the user has access to (in the case of delegated permissions) or everything that EWS can access (with application permissions).
EWS has all or nothing access model and there is no granular scoping for limiting data access in a mailbox. Whereas, Microsoft Graph offers granular permissions to specific features within an Exchange Online mailbox. For example, it is possible to allow an application to only read mail messages, and have no access to calendars or contacts. The effective permissions for delegated authentication is the intersection of the user’s privileges and the permissions that have been consented for the application. For application authentication, the effective permissions are the set of permissions consented to by an administrator.
Impersonation
EWS impersonation provides a mechanism for EWS applications that run as a service account to act as a user. This allows the app to take actions, such as sending an email, that appear to come from the impersonated user.
With Microsoft Graph, there are no service accounts. Instead, permissions are granted to applications directly. The application authenticates using client credentials flow with its own identity. By default, admin consent grants access to all users’ mailboxes, but apps can be limited to specific mailboxes by an administrator. The way to achieve Impersonation in Microsoft Graph is by making use of app-access policy and application permissions.
Want to have a deeper discussion? Contact us today!