Share via

Know When Your Azure Identity Won’t Work with Office 365 APIs

  • Article

As those of you who are familiar with Office365Mon know, we heavily leverage the Office 365 APIs in our solution.  It’s been a key player in being able to issue now over 100 million health probes against Office 365.  I know and have talked to lots of you as well that are starting to build apps that leverage this same infrastructure for your own solutions.  As you develop these solutions based on the Office 365 APIs, it’s pretty important that you understand the scenarios where the Azure access token you get will and will not work to access Office 365 resources.

First, a couple of basics.  When you get an access token, for purposes of our conversation here today, the token represents your identity that is going to be used to access a resource in some way.  There are exceptions to this, i.e. app only tokens, but this post is about user identities and Office 365.  When you try and access a resource, you say here is my access token, I want do this with the content – for example, I am Steve, I want to read the email in my inbox.

The problem is this – what I just described is a common scenario, and it works well today with the Office 365 APIs.  But there are actually at least four scenarios, and you may be surprised to learn that the Office 365 APIs only work with one of them.  Part of the reason in writing this blog post is to make sure you all are aware of that, but also to hopefully drive a discussion with the folks that own the service so that they can give some consideration to expanding their support of these other scenarios in the future.  Here’s a quick run down on the scenarios that I’ve looked at so far; there may be others.

  1. I own or otherwise have direct rights to a resource – WORKS!   This is the first scenario I described above – for example, when I want to access the email in my inbox, or if I’m part of a SharePoint group in my Office 365 tenant and I want to access content in that site.
  2. I have been granted delegate rights to a mailbox – DOESN’T WORK!   In this scenario, I’ve been granted rights to another mailbox.  Now if open up Outlook for example I can read the mail in that mailbox no problem.  If I’m using the Exchange Web Services (EWS), I can access the mail in that mailbox.  But if I’m using the Office 365 APIs, it doesn’t work.
  3. I have been invited to a SharePoint Online site – DOESN’T WORK!   In this scenario I’ve been invited as an external user to a SharePoint Online site.  I use my Azure AD credentials to accept the invitation and I can connect to the site in the browser.  However if I try and use an Azure access token against that resource it fails with an access denied error.
  4. I have been added to an Azure tenant using the Azure B2B feature – DOESN’T WORK!   This is similar to #3 – after being added to the Azure tenant with the B2B feature I can be added to a SharePoint Online site and access it just fine in the browser.  However my Azure access token will only get me an access denied error if I try and use it on that site with the Office 365 APIs.

The key and common thread in all of these scenarios is that I am using my Azure AD identity.  It is a durable, immutable identity containing an immutable identifier known to Azure AD.  Even though I’m using that immutable identity, there is still a disconnect between it and all of the ways in which it has been granted access to resources in Office 365.  That is to say, there is a disconnect in the Office 365 APIs; in the browser applications they have this figured out.  Make sure you know these limitations, and let your favorite Microsoft human if you would like to these disconnects eliminated for a comprehensive and integrated identity and resource solution.

Comments

  • Anonymous
    February 01, 2016
    Estrenamos nuevo mes en el blog  y toca compartir con todos vosotros la 6ª Edición del recopilatorio