PREVIOUS: Security in SharePoint Apps - Part 1
In Part 1 of this series I described how to think about an App Principal, and I mentioned that it is one of the main actors in determining who has rights to what content. The other actor, of course, is the User Principal. Between the two though, there are four possible security contexts that SharePoint may use when responding to requests for content. In this post we’ll take a look at all four and how we determine when we use which.
It’s best to look at the process of determining the security context through a familiar paradigm, like a flowchart. So here’s how our flowchart would look – our starting point is a request coming in to SharePoint, and we’ll take it from there.
So those are the four identity contexts that we can have when making a request for content from SharePoint. They’re important to know, because we can wind up in any of them when writing apps in general…but for purposes of this series we’re really just going to focus on User + App and App Only requests. To make it a little easier to rationalize, here’s a picture of the flowchart I described above:
In the next post in this series we’ll talk about the simplest environment to write code in – an on-premise Low Trust App.
NEXT: Security in SharePoint Apps - Part 3
It is worth noting that App Only Policy requires OAuth to generate the tokens and hence it cannot be used in SharePoint Hosted Apps. It can only be used in Auto Hosted and Provider Hosted Apps.
@Vardhman - With Provider Hosted and Auto-hosted you have to cross the process boundaries requiring you to prove your identity where as with SP Hosted Apps, it's all happening within the same process where you have already authenticated yourself. Still,
I would believe so, although we don't have the Token generation available, who knows we get the same in one of the exposed API's down the lane, considering we do have the App having it's own identity elements already.