The authentication part seems right, but I’m not sure about the authorization part. What I mean is that it is easy to verify the user’s identity, but really difficult to verify what the user should be able to access.

According to the architecture laid out here, the routes would have to be able to contain enough information to always return that, which isn’t always the case.

Another issue is when users have access to thousands of different resources all with different IDs, you can’t write a single regex, which means with the current strategy that would required iterating through many rows in your relational table to answer that question.

Something else that comes to mind is the separation of roles outside of the authorization service. You mentioned you have microservices, but the drawing makes it look like you actually have a distributed monolith.

Lastly, it looks like this is hard coupled to a REST paradigm. While that is definitely awesome, it doesn’t allow for handling more nuanced access based on other parameters. For instance I want to update a field in an order, let’s say the quantity. So we check PUT /orders/${orderId} for a particular user, okay they have that, but what if I want to update the price of the order, and you want to exclude the permission from the user. How would you do that?

Realistically to solve these sorts of problems you might need more features. I know there are Authentication services out there that try have some solutions for this, was there a reason you aren’t using something like RBAC through Auth0 or Okta, or access records via Authress?