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

john in t veld 21 Reputation points


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!

Office Development
Office Development
Office: A suite of Microsoft productivity software that supports common business tasks, including word processing, email, presentations, and data management and analysis.Development: The process of researching, productizing, and refining new or existing technologies.
3,453 questions
Microsoft Exchange Online Management
Microsoft Exchange Online Management
Microsoft Exchange Online: A Microsoft email and calendaring hosted service.Management: The act or process of organizing, handling, directing or controlling something.
4,158 questions
Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
19,357 questions
0 comments No comments
{count} votes

Accepted answer
  1. Glen Scales 4,431 Reputation points

    > 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).

0 additional answers

Sort by: Most helpful