0

According to the RFC-6740 Specification, Section 1.1, a Resource Owner is defined 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."

In the case where ownership is not a person, but e.g. an organization unit, who is legit to perform the OAuth2 authorization? Only the account representing the unit, or also users associated to the unit?

To give an example:

  • Let’s say there is a bookstore chain, with stores in Montreal, Lyon, Munich etc…
  • Individual stores can update how many copies of a given book are available. This resource is owned by the organization unit (the Resource Owner) per specific location.
  • So somewhere in the bookstore REST interface in our Resource Server there is a REST resource: /bookstore/storelocations/{location}/{isbn}
  • If the Lyon bookstore wants e.g. to update the amount of Harry Potter copies in store, they can do so by sending a [PUT] to /bookstore/storelocations/Lyon/9780747532743, with the updated amount in the HTTP body.

Let’s assume a new Client “StockReplenisher” enters the stage. It is a service that delivers book copies to locations. So now our Lyon organization unit wants to authorize StockReplenisher to change the amount of copies in the Lyon store, using OAuth2.

Question: Based on the Resource Owner definition, should the ownership of the /bookstore/storelocations/{location}/{isbn} resource be considered...

  1. strictly individual, that is to say is it tied to a unique account representing the Lyon organization (and hence only this account can authorize the StockReplenisher Client).
  2. shared, that is to say indirectly owned by any employee of the Lyon organization (and hence there is no Lyon account in the system, but any employee is a Resource Owner and can authorize the StockReplenisher Client to access the Lyon resource.
    (Let’s assume all employees are trusted, for simplicity)

I’m aware both can be implemented, my question is not about technical feasibility, but whether the second option is an OAuth2 anti-pattern (because of the non-individual resource ownership) or whether it is a perfectly valid OAuth2 scenario to assume multiple Resource Owners for a single resource endpoint.
Is there a part in the documentation / specification any other reference that provides clarity?

Note: the semantics of ResourceOwner has already been discussed with one of the RFC authors, but it seems not with respect to ownership being individual or not.

I've read the RFC specification, the Manning book OAuth2 in Action, and searched StackOverflow.

m5c
  • 45
  • 7

1 Answers1

1

No, definitely not. In this case the 'owner' may have access to a set of resources, and doesn't even have to be the 'owner' in the traditional access control sense.

In a sense the 'resource owner' can grant access to an OAuth2 application to one or more of the resources they have access to. It's really privileges to those resources that are delegated, not ownership.

What resources/privileges are shared is completely up to the implementer and OAuth2 doesn't put much restrictions to this.

Evert
  • 93,428
  • 18
  • 118
  • 189
  • I'm not sure how to interpret this with respect to: Is one resource strictly owned by a single resource owner. (Lyon bookstore employees, of whom each can authorize a Client for the Lyon resource). Maybe not clear enough in the question, but I was wondering about one resource being owned by multiple resource owners, not so much about one resource owner owning multiple resources. – m5c Jul 24 '23 at 17:20
  • @m5c the user ultimately grants the app to act on behalf of the user. If that user *had* access to some resource by virtue of being part of a group (bookstore employees), the user can delegate that access all the same. The main point is that OAuth2 does not dictate what is shared. – Evert Jul 24 '23 at 17:57