What happens when I roll out my EWS app with oauth? What do users have to do in order to use it?

Question

Hi,

I have an old EWS application that a number of companies use on office 365. it runs as a service and accesses mailboxes with application impersonation and subscriptions.

It uses basic authentication so I need to update that to oauth before 10/1/2022

I'm in the process of doing that and some things are not clear because i have no experience with, for example, AAD

I am using this doc as a guide : https://learn.microsoft.com/nl-nl/exchange/client-developer/exchange-web-services/how-to-authenticate-an-ews-application-by-using-oauth

So I register my app name in AAD as multi tenant and configure it for app-only authentication and follow the rest of the guide to implement to code.

but then what? I have no idea at all how the authorization is going to work for the users.

Is there a document describing the workflow?

I mean, i send my executable to the user, but what do they have to do in order for it to access their office 365?

It currently uses a service account which has application impersonation rights. That's no longer needed right? But is there any configuration or authorization needed for the admin in the other office 365 tenant?

thanks for your time!

Answer 1

> mean, i send my executable to the user, but what do they have to do in order for it to access their office 365?

if your providing client side code to the customer and its not a hosted product then a multi tenant app registration might not be the best method for you from a client security point of view there is a good discussion in https://stackoverflow.com/questions/42162963/azure-ad-multi-tenant-with-daemon-service-and-authorization-code-grant-flow-c

Typically for a hosted application your client would consent to your app then apply an app policy to limit https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access your apps mailbox cope if necessary . The issue is if your service became compromised and the attacker was able to access the certification/secret then will then be able to access all of your customers using those credentials. In a hosted scenarios this is the same as storing user creds so there is no real benefit of having separate secret information per tenant. But in your instance if you providing dll's or exe where the certificate or shared secret could be extracted by a disassembler then anybody who has access to you source could obtain this and use it to attack any customer that has consent to your app. So at the moment whatever process your using to store credentials for the client on the client side you might need to use this to store a client specific application registration (single tenant).

Its really up to you to determine the security risk associated with your app and the methods you have used to secure the secret information and for an ISV what the consequences are if you are compromised (multi tenant is the easiest option from a install/support point of view).