Authentication to Exchange Web Services without username/password and without Admin involvement

Question

Here's the scenario

• 3rd Party App, with a back end. Customer uses the app.
• Back end needs to access user's exchange information, assumedly via EWS
• Back end is running in our datacenter/cloud, not customers.
• Cannot require local administrator involvement
• Want to avoid storing username/password in our back end.
• Want to support both Office365 and on-premise.

I believe this is currently impossible, but wanted to verify:

• Impersonation would be a great way, but requires Administrator
• Token based authentication is not used for this. It is for a mail app to use for SSO to the backend, not for the backend to access Exchange.
• OAUTH would be ideal, but is a) for Office365 only currently b) requires a portion of the back end to be hosted by Azure c) The Azure install has to be linked to the Office365 install and is for the local administrator only.

Is my analysis correct? Any options I've missed?

Answer 1

So to add to this mostly correct answer from Jason:

1. using pure rest, you need only create a "multitenant" application and users can self-consent.
2. You can also use an OAuth token to authenticate to EWS - but only if the delegate Full Access To Mailbox is selected. This also doesn't require admin consent but is a big scope (but necessary because EWS doesn't understand scopes)

Answer 2

You're mostly correct. OAuth is currently for Office 365 only, so that would rule out on-premise. However, with OAuth you do not have to host your back-end in Azure. You would need an Azure tenant to register your application, but the app itself is not required to be hosted in Azure. If you use EWS, then even with OAuth you will need some admin involvement, because EWS requires a permission scope that requires the app to be registered in the target tenant, users can't consent using a registration from another tenant.

If you use the REST APIs, which are in preview, you wouldn't need an admin's involvement, users could consent for themselves. That would get you almost where you want to be (assuming the REST APIs provide the data that you're after), but wouldn't support on-premise.