OAuth - What exactly is a resource owner? When is it not an end-user?

Question

The term "resource owner" is defined in the OAuth v2.0 Specification, as "An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user."

My question is, when is a resource owner not an end-user? I would appreciate explanation through examples that could be real use cases. For example, if the protected resource is a Facebook user's photo, is the resource owner Facebook or the Facebook user who uploaded the photo? Also, why is the resource owner (that is also a person) be considered an end-user if that person is not even a user of the application that is implementing OAuth? And, if the Facebook user is the resource owner, then what role does Facebook play in this exchange?

Solution 1

Resource owner can be a machine, not just people. There are many cases where no humans are involved in the entire OAuth flow, especially in enterprise setups. At least, that's what I meant when I introduced the term in RFC 5849 (and later in OAuth 2.0).

Solution 2

Consider the situation where a resource owner is a corporation, perhaps one with policy that enables / disables access to a resource.

Consider an example of art; let's say you want to make your domicile look better with a piece of art; there are several places you can go to (Costco, for example) where you can choose a piece of art, to have that printed on the medium of your choice in the size of your choice, and delivered to your home.

Here's the thing; Costco isn't the owner of the licensing rights for that piece of art; that's outside of the realm of their business. They sell stuff, they don't collect art. What they do is they negotiate with the content owner (owner of the license for the art) for the rights to use that art in a print, which they then create and deliver to you. You pay Costco for the artwork; Costco then pays the licensor a portion of their payment from you for the right to use the artwork.

This works as well in the situation where you already have a relationship with the resource owner; let's say you've negotiated and purchased the rights to some music, for example. You're not the owner of the music, in that you don't have the right to resell the music; but you do have the rights to listen to it (this is a standard DRM situation). Now let's say that you want to play that music through a website; you can make a request to the website for that music; the website can contact the content owner (licensor, really, but it's effectively the same) with your identification; the content owner can then decide whether or not to grant the website access on your part to the content, based upon your terms.

Hope that clears some things up.

Solution 3

Consider you have a Facebook app.

Now you want to get statistics (in other words, "Insights") on all your users' activity.
In this case, the resource ("App Insights") is owned by your app, not each user.
So your app gets a client access token (called 2-legged OAuth) and access its insights.

Facebook also provide "Page Insights" as a resource which is a page's fan activity. In this case, the resource is owned by a page not by the page's fans, so your app gets the page's access token.

However I can understand your confusion.

Previously Facebook allowed page insights access using either page owner's access token or page's access token.(It means Facebook handled it as a resource both of the page and the page owner; now only page's access token is allowed)

At last, in all case, Facebook acts as "Authorization Server" and "Resource Server". It authenticate users and get approval of the client access to their resources. (Authorization Server). It serves resources too.(Resource Server)

Solution 4

My company collaborates with a screen sharing video conferencing provider. Our users can use their solution as part of our offering. The communication between us and the third party tool takes place through calls to an API, using 2-legged OAuth.

We are not a person, a better wording is perhaps an external system, but we are definitely a resource owner - since we pay for the resources that we use and we are the entity that authorizes the calls to the APIs.

Furthermore, in the Facebook example you mention. The resource owner is the person who uploaded the photo. That person is also the end user. The one for whos benefit a third party application issues API calls.

Solution 5

I would like to emphasize @Paul Sonier's solid response with a more concrete example related to OAuth 2.0.

In an enterprise setting, employees of a company may want to access content on a file storage service (e.g. Google Drive, Box.com, DropBox, etc.) under the aegis of the company's enterprise account.

Such services may already have Single Sign-On arrangements where users' accounts with the service provider are dynamically provisioned or provisioned in bulk.

Importantly, employees typically sign over all rights to any documents or other work they produce to the company. In a legal sense, the company and not the end user is the resource owner.

In such a situation, the OAuth2 authorization step is superfluous. The company, in it's contract with the service provider, might reasonably say, "consider any user session authenticated from our IDP as pre-authorized for all our applications". A service provider could simply skip the authorization step for these apps and, btw, save thousands of employees a confusing step and lots of calls to the support desk, etc.

At the end of the day, an authorization grant just an entry in a data store and subject to policies that are outside the OAuth 2.0 specifications. There is nothing in the OAuth 2.0 specifications that prevents or discourages such "bulk authorization". It's just a matter of agreement between the service provider and the true resource owner.

Note, this application level authorization is distinct from file and directory permissions, which is usually managed out of band as well. I.e. storage services provide a UI for managing user and group level access to files and directories. OAuth 2.0 clients, then, acquire user level tokens (most support only the consumer oriented "authorization code" grant type).

View more solutions

Comments

[smartcaveman]

but in the Facebook example - Facebook "authorizes the calls to the APIs" and "pays for the resources", so why is the user the resource owner?

[Andrew Arnott]

Facebook doesn't authorize access -- the Facebook user does. Facebook just facilitates that authorization.

[Jon Nylander]

The resource owner owns the resource, in your example the picture that he/she/it uploaded. The resource owner can also authorize another app to access that resource (picture). The resource owner can be an individual. If so, he/she can be called an end user.

[smartcaveman]

this analysis was very helpful. However, with regards to the second part of my question- Can you think of a situation where the resource owner is not a person? It seems like what you have addressed is a situation in which a non-person is delegated certain access-granting permissions by a human resource-owner, but the resource-owner would still be a person. Am I confused?

[smartcaveman]

@Paul Sonier, Thank you for this. Help me make sure I am getting it. If I am buying licensing rights (a resource) from Costco, Costco is acting as an intermediary between the the artist (resource owner) and me (the client). Costco seems to be acting as an equivalent to both the roles of the resource server and the authorization server in OAuth. However, I have no communication with the artist, only with Costco. So, I have no actual communication with the resource owner. This seems like an equivalent to an implicit authorization grant

[smartcaveman]

@Paul Sonier, In both the Costco and the DRM situation, there is no direct contact between the client and the resource owner. In the DRM situation, there is a request to a proxy resource owner, that is not actually the resource owner, but for the sake of the interaction plays that role. So, a few questions: (1) Am I getting this all correct so far? (2) Is there a need to distinguish between a resource owner and its proxy? (3) If so, how do you account for a potentially infinite chain of resource owner proxies with OAuth?

[smartcaveman]

@Paul Sonier, (4) Once I have purchased a license for music, am I not now the resource owner of that license? This would account for the apparent lack of interaction with the DRM license provider, because the resource server would actually just be authenticating me as the correct resource owner of a license. It would then only be a function of the website as an authorization server to authenticate my rights to listen to the song through the website. Am I correct in this?

[plankalkul]

@smartcaveman: I think you've got it exactly correct; one point is that there is no distinction between the resource owner and the authorization proxy. If a resource authorization proxy says (trustfully) that they grant access to a resource, it doesn't matter if they're the owner, or the owner's agent, or if they've got a homing pigeon to find out if it's authorized; effectively, it's all the same.

[plankalkul]

@smartcaveman: and the other minor clarification is in the music example, consider the situation where you have a license, but not the content; in that situation, the putative website is not only validating your license with the resource owner / licensor, but is also (potentially) streaming the content.

[plankalkul]

@smartcaveman: but in general, you've got a good grasp on the situation. In the specific instance with Costco, they actually don't retain the resources directly; they're querying for the resources based upon the query parameters given by the user, and providing the resource (art) to a third party (the printer) on behalf of the user. It's an interesting process.

[smartcaveman]

@Paul Sonier, (1) I can see a reason why a distinction between the resource authorization proxy and a resource owner may be relevant. Consider that the authorization proxy's authorization data is not always as current as the resource owner's data. If a system had reference to both sources, it would need to know which of them to trust if the values were to conflict. I may cache Facebook's authorization information for a specific user, and only authorize directly with Facebook if there is a new modified_date on the Facebook resource.

[smartcaveman]

@Paul Sonier, So, it seems that the resource owner and authorization proxy may sometimes require distinction in the interest of determining priority. Do you seen an error with this? (2) By the printer (third party in the Costco example), I assumed you meant the company that prints the art. Right?

[smartcaveman]

Thank you for taking the time to address this question. Am I correct in my understanding that, by a resource owner, you mean nothing more than either (a) a person, or, (b) a server than can respond to authorization requests with authorization grants? Has this meaning expanded at all since its initial conception, or would you consider the examples in this discussion to be over-analyzed?

[Eran Hammer]

I think this discussion is verging on over-analyzing it. The term has not changed since I first introduced it. The easiest way to understand it is by replacing it with 'the person who owns/controls the resources', but keeping in mind that it doesn't have to be a person. For example, it can be your operating system granting access requests to OS resources to applications based on some internal policy (running as root or not, etc.). I'm not aware of any non-human use cases so this is mostly theoretical.

[Cody A. Ray]

@EranHammer in an enterprise environment (e.g., where a bunch of users belong to an organization) i've heard that "client credentials" shouldn't be used to access org data. But couldn't a "service account" just be an oauth2 client using client_credentials grant? And that service account is tied to the owning org?