SharePoint Dragons

In SharePoint 2013, SharePoint Apps purchased from the SharePoint Store from SharePoint Online leverage the OAuth security protocol to communicate with SharePoint.

In these cases, the client application (or: the SharePoint Aps) sends requests to the resource server (SharePoint) which hosts the resources that are controlled by the end user (or resource owner) and is capable of accepting and responding to protected resource requests using access tokens. The three roles in OAuth, consisting of client, resource server, and resource owner, are also fondly known as the OAuth Love Triangle.

In addition, the OAuth infrastructure requires the presence of an authorization server, a trusted server authenticating client applications and issuing access tokens to client applications authorizing them to access end user resources. It is possible that the server also acts as the authorization server, but the authorization server as a separate entity is equally possible. A single authorization server may serve multiple application servers. The OAuth specification doesn’t address the interaction between server and authorization server, so that implementation is completely left to the discretion of the vendor implementing OAuth. For SharePoint Online, Azure Access Control Service (ACS)  is the authorization service.

As you may have noticed, OAuth recognizes client applications (in this case, SharePoint Apps) having their own identity recognized apart from user identities. This notion sets OAuth (and S2S, the default security protocol used by SharePoint Apps in on-premises installations) apart from other authorization protocols.

Doesn’t it seems like all architectural problems in the world can be solved by adding one or more abstraction layers? OAuth is another example of this provoking thought.