We plan to refactor our company system into a micro-service based system. This micro-services will be used by our own internal company applications and by 3rd party partners if needed. One for booking, one for products etc.
We are unsure how to handle roles and scopes. The idea is to create 3 basic user roles such as Admins, Agents and End-Users and let the consumer apps to fine-tune scopes if needed.
- Admins can create, update, read and delete all resources by default (for their company).
- Agents can create, update and read data for their company.
- End-Users can create, update, delete and read data, but cannot access same endpoints as agents or admins. They will also be able to create or modify data, just not on a same level as agents or admins. For example, end users can update or read their account info, same as agent will be able to do it for them, but they can't see or update admin notes.
Let's say that agents by default can create, read and update each resource for their company and that is their maximum scope which can be requested for their token/session, but developers of client (API consumer) application have decided that one of their agents can read and create only certain resources.
Is it a better practice to handle this in our internal security, and let them write that data in our database, or let clients handle that internally by requesting a token with lesser scope, and let them write which agent will have which scope in their database? This way we would have to track only token scopes.
The downside of this, is that our team would also need to create fine-tuned access mechanisms in our internal applications.
With this way of thinking, micro-services and their authorization system should not be bothered with clients needs, because they are only consumers and not part of the system (even though some of those consumers are our own internal apps)?
Is this delegation a good approach?