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

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-use开发者_如何学Cr."

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?

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

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.

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)

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.

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

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.

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?