Office 365 APIs

Posted on 3/23/2014 @ 8:33 AM in #SharePoint by | Feedback | 2268 views

I’ve been looking at the new Office 365 APIs that Microsoft has released at SharePoint Conference 2014 with great interest. I wrote about this in my SPC14 overview too.

Here are some high level points:

On-Prem and Office 365 diverge: In short, Office 365 APIs represents what I have predicted for a long time – the client side APIs for Office 365 and SharePoint on-premises will diverge further and further, with Office 365 getting most love. This is not necessarily a bad thing, but organizations sticking to on-prem with stubborn love, are going to feel left out.

Open Standards: The good news is, I am absolutely thrilled to see Microsoft embrace open standards like OAuth and REST instead of a home grown concoction like CSOM. REST/OAuth and open standards is always a better deal people, there are many OAuth libraries I can use on other platforms, though we really could use an iOS SDK too :). (They did release an Android SDK). Anyway, you could do OAuth on iOS today, but replaying the HTTP stack. Though, it looks like they are not ditching CSOM either. I don’t mind CSOM sticking around as long as it isn’t at the cost of supporting open standards.

Windows Azure AD: Another interesting bit I see, is the hardcore tie in/buy in of Windows Azure AD. This is also a pretty good move, since Azure AD supports pretty much all standards you care for, and is shaping up into the singular identity resource for the cloud, pretty much like your on-prem AD was for on-prem. Notably, Azure AD != On-Prem AD. The naming is confusing, but the marketing sets it in the right place – this is as important for the cloud, as what on-prem AD was on prem.

A Discovery Service: This is a big deal. One of the biggest criticisms of the fantastic _api REST API in SHarePoint 2013 was, it was hard to figure out what is supported and what is not. Beta2 supported $metadata, which was removed in RTM and later added. Still, left a lot to be desired for. The Discovery Service fills that gap (atleast for Office 365). It will allow you to find endpoints for all Microsoft services – Office 365 and Windows Live. The pre-requisite is that it works only with AzureAD or Microsoft Accounts. See, like I said, online is the new puppy, on-prem is in hospice.

Future Path: The current set of APIs include a very limited Files/Folders and Mail/Calendar APIs. Though this is destined to grow to much much bigger going forward.

The Common Consent Framework: Read the above about Windows Azure AD first. The Common Consent framework is the Office 365 version of OAuth built on Azure AD. Here is how it works,

  1. User accesses the app, assuming the you are not granted access yet, Azure AD shows consent dialog.
  2. User or Admin grants access, which causes Azure AD to send an AuthCode to the App.
  3. App sends the AuthCode, AppID, AppSecret and resource to receive an access token and multi-resource refresh tokens from Azure AD
  4. App presents the access token + app secret to the resource
  5. The resource grants access

Now the cool thing is, if the App needs access to a second resource,

  1. App present the multi-resource refresh token to Azure AD for resource,
  2. Azure AD shows no consent dialog (user has already consented), and Azure AD will generate multi-resource refresh token + access token for Resource 2.
  3. With this, the App is able to gain access to Resource 2.

Native clients can use either webframe embedded approach, or can skip passing the secret.

You would note that the key difference here is the usage of a multi-resource refresh token. Refresh tokens are used in the current gen of OAuth2 secured SharePoint apps as well. A multi-resource refresh token as the name indicates, a token issued by one resource, that can then be used to authenticate the app or user to another resource. This is the key difference between the current crop of OAuth2 apps, vs. what we see in the newly introduced Office 365 APIs.

Sound off but keep it civil:

Older comments..