SharePoint 2013: Claims Infrastructure – Part II

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

Welcome to Part II of SharePoint 2013 Claims Infrastructure.  Previously I wrote about the Distributed Cache Service and how it will revolutionize the authentication model in SharePoint 2013 (along with a lot of other great use cases).  In this post, I want to focus on the way Open Authentication (OAuth) works with SharePoint Apps and the Client-Side Object Model (CSOM).
OAuth is new in SharePoint 2013 and is implemented specifically to enable working with SharePoint Apps and the CSOM.  OAuth is identity provider agnostic, meaning that it doesn’t know and, more specifically, doesn’t care who your identity provider is.  It provides a way for SharePoint and your App to mutually verify each other before they start talking by using a third-party broker.  In most instances, this broker will be Azure Access Control Services (ACS), but it can be your internal SharePoint server if you’re using an on-premise app.  The overall OAuth App launcher process looks like this:

1. User authenticates to SharePoint via claims-based authentication and clicks on an App
2. SharePoint requests a Context Token for the App specific to the User from the Authentication Server
3. The Authentication Server validates the request and returns a valid Context Token that has been signed.  The encryption key is trusted by SharePoint
4. SharePoint returns the Context Token to the User and directs the User to the App
5. User POSTs the Context Token to the App as part of the initial request
6. App takes the Context Token, extracts the Refresh Token and sends it to the Authentication Server to obtain an OAuth Token for accessing SharePoint
7. Authentication Server validates the Refresh Token and returns the OAuth Token that the App server can use with SharePoint.  The OAuth Token contains the User’s identity and the App’s identity and is trusted by SharePoint because it’s signed by the Authentication Server
8. (Optional) App requests data from SharePoint via REST/CSOM using the OAuth Token as its identity
9. SharePoint returns requested data to App
10. App renders itself to the user as HTML, JavaScript, and CSS

This process is kind of complicated, but the general principle is that both SharePoint 2013 and the App trust the third-party broker which validates that both services are who they say they are.  Generally, the Authentication Server will be Azure Access Control Services, but on-premise SharePoint 2013 Farms and Apps can be entirely self-contained and cut off from the Internet if necessary.  In such a scenario, the Subscription Settings Service Application in SharePoint acts as the broker.
You’ll notice that step 8 (and thus step 9) is optional because an App doesn’t necessarily need to call into SharePoint to get data.  However, once it has the OAuth token, it has the capability.  In addition, security for Apps is different.  An App can have additional security permissions above a standard User, meaning that anyone authorized to use the App can potentially have elevated permissions.  This situation exists because CSOM doesn’t have a similar SPSecurity.RunWithElevatedPrivileges construct that exists in server-side code.
OAuth facilitates both dealing with claims-based authentication without getting a FedAuth token and getting the user’s identity without asking for credentials.  This coupled with the expanded feature set of CSOM should lead to many interesting and exciting apps.  Check in soon for the final part of this series: SharePoint 2013 Claims and Search!