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?

Bichromate

Answer 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).

Flagstaff

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? – Bichromate

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. – Flagstaff

@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? – Carolinacaroline

Answer 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.

Calli

@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 – Bichromate

@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? – Bichromate

@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? – Bichromate

@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. – Calli

@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. – Calli

@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. – Calli

@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. – Bichromate

@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? – Bichromate

Answer 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)

Synclastic

Answer 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.

Sequestrate

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? – Bichromate

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

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. – Sequestrate

Answer 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).

Gerhardt

Answer 6

From the spec:

Resource Owner - 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

From this definition, I read that many entities may be capable of granting access to a protected resource.

As you've noted, human examples are easy to grok - When you request access to my protected photo, only one entity is capable of granting access. That entity is me. I must perform some action to grant your request. Depending on the application this might involve clicking a button, sending a text message, speaking, clapping, whatever. The mechanism by which my action is captured & processed is not relevant to this definition.

Continuing with this example, lets say another entity could grant access to my protected photo. Imagine you are a trusted business partner of the photo hosting service. Or perhaps you're another team at the photo hosting company, and your servers operate within the same datacenter. In this scenario, it might be desirable to automatically grant you permission to the protected photo. If the resource server decided to automatically grant you access (because of who you are), this would represent a second entity. Here, this non-human entity has decided (in all its wisdom) that your access request should be automatically accepted.

Mansard

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? – Bichromate

Answer 7

The Resource Owner is usually the Foreign Key used to retrieve records from the protected Resource Server.

If a user owns photos in Resource Server, and the photos can be retrieved from the Resource Server with user_id.

The Authentication Server retrieves a user_id in the the authentication process (Username/Password/OTP).

A tamper-proof (signed) JWT token ensures the same user_id is used to retrieve records from the Resource Server.

Authorization Server generates a JWT token (Access/ID) with the Foreign Key: user_id

Resource Server receives the JWT token to authorize the retrieval of records (Resources) owned by Resource Owner (user_id).

SELECT * FROM photos WHERE user_id = '[jwt.payload.user_id]';

Now, replace user_id with any (non end-user) Foreign Key, e.g. transaction_id

SELECT * FROM files WHERE transaction = '[jwt.payload.transaction_id]';

To determine Resource Owner, ask yourself:

1. What Resource (Foreign) Key is required to retrieve Resource Owner's records from Resource Server?
2. What Authentication (proof) is required to retrieve Resource Key from Authentication Server?

Profit