I’m trying to understand how resource ownership works in OAuth2. The spec says a resource owner can be a person or an entity. But what if it’s a group or organization?
Here’s my situation:
I’ve got a bookstore chain with branches in different cities. Each store can update its book inventory through an API. The inventory is owned by the store location, not individual employees.
Now we want to let a new service called BookFiller update inventory levels. Should we:
Have one account per store that can authorize BookFiller?
Let any employee from a store authorize BookFiller for their location?
Option 2 seems more flexible, but is it okay in OAuth2? Can multiple people be resource owners for the same thing?
I’ve read the OAuth2 spec and some books, but I’m still unsure if shared ownership is allowed or if it goes against OAuth2 principles. Any insights?
oauth2 can handle shared ownership, bro. think of each store as its own entity. set up oauth clients per store, then use roles to let employees grant access. for bookfiller, give it a seperate client for each location. u can use scopes to control exactly wat it does. just make sure u log everything n can revoke access if someone messes up
In my experience with similar scenarios while developing inventory management systems for multi-location retail chains, OAuth2 can indeed support shared resource ownership if implemented carefully. We treated each store as the primary resource owner while delegating permissions to specific employees who could act on behalf of their store. This method maintained centralized control at the store level while allowing flexibility for operations such as inventory updates. For integrating a service like BookFiller, I recommend setting up individual OAuth clients for each store and using role-based access to handle delegation. This approach adheres to OAuth2 principles and offers precise control.
OAuth2 is flexible enough to accommodate shared resource ownership, which is quite common in enterprise scenarios. In your case, treating each store location as a resource owner is a sound approach. You can implement a hybrid of your options by setting up store-level accounts that act as the primary resource owners, but then use fine-grained permissions to allow certain employees to grant access on behalf of the store.
For the BookFiller integration, I’d suggest creating separate OAuth clients for each store. This maintains clear boundaries and allows for store-specific policies. You can then use scopes to define exactly what BookFiller can do with each store’s inventory.
Remember to implement proper auditing and revocation mechanisms. This way, you can track which employees authorized what actions and easily revoke access if needed, without disrupting the entire store’s operations.