Office 365 / EWS Authentication using OAuth

Question

I\'m trying to log onto Office 365 Exchange Online using OAuth and EWS Managed API.

I am able to use connect to the Office 365 Web API\'s (REST), so I do have a vali

Answer 1

You can use saml if from a certified domain of the aad, and you swap that token using the ms online sts. I did this, and its trivial to find my writeups on the web.

Interested to dump it all and now use an aad issue access token.

The older model is cute in some ways, as you are not tied to aad oauth, for your own app, only becoming tied to aad land when talking to microsoft properties. If one has, with openid connect, a vendor mobile token (a tgt, in all but name), perhaps i can live with some codependence.

So i have an aad (netmagic.onmicrosoft.com), with certified domain registration (rapmlsqa.com). Do i go make a webapi class app in aad, assign THAT the office permissions?

Answer 2

TokenCredentials is not the right class to use in this example. Like Jason mentioned put in place for other reasons. As a note and to clarify using this and/or SAML tokens will not work in Exchange Online with EWS. Only OAuth based access is supported. To make this work we put a OAuthCredentials class in EWS Managed API. In your code you can "var credentials = new OAuthCredentials(token)". Be aware that EWS Soap only supports full "user_impersonation" / "full access to the users mailbox" rights. Granular permission such as Calendar.Read are only available with EWS Rest APIs. While "Full mailbox access" requires an admin to consent, admins from other tenants can consent as it is a web app. In case you want to develop a native app, the app has to be directly registered in the app of the tenant it runs in order to use "Full mailbox access".

Answer 3

You can use OAuth to connect to EWS (as opposed to REST), however, it's not as smooth. EWS requires the special "Have full access to a user's mailbox" delegated permission in Azure Active Directory, which requires an administrator to register it. This permission also doesn't "travel" outside the organization, so there is no user-consent scenario for EWS. Essentially, the only scenario that this works for is an administrator registering the application for your own organization.

Check your app registration in Azure and make sure you have that permission assigned.

Assuming that you have the permission assigned, I've made this work in two ways.

1. The simplest: Just add the token you get back to the request headers in an Authorization header, like so:

   ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2013);
   string accessToken = GetAccessToken();
   if (!string.IsNullOrEmpty(accessToken))
       service.HttpHeaders.Add("Authorization", "Bearer " + accessToken);
   

2. More complex: Implement your own credentials class that implements the ICredentials interface. Pass this class into the constructor of the Microsoft.Exchange.WebServices.Data.OAuthCredentials class, and assign the new OAuthCredentials object to the Url property of the ExchangeService object.