I have an application that uses Identity Server 4 and open id connect for authentication and authorization. I am now in discussion with the system architect that wants to do a few changes when it comes to the handling the user permissions. Within this application, a user can be a part of a single or multiple regions, and within this region the user can be a part of a single or multiple customers. These users have both regional roles, and customer roles. Within each region, a user can (in worst case, but very possible scenarios) be a part of over 150 customers with different roles in each one, which could result in around 2500 permissions in total.
When the user is browsing the application, the person selects different regions and customers that the user is currently browsing. This means, that a user has different permissions within a resource depending on what region/customer it is currently working on. My system architect suggests that these permissions should be stored within the access token being sent to the resource, so that the resource would check if the user is allowed to perform this action for the specified region/customer, and that these permission claims should update when a user changes region and/or customer. My worry is that these permissions seems a bit too dynamic to be handled inside of an access token as these may change multiple times during a user session within the application,
First of all, is it even possible to tell identity server that "User A just selected this region/customer, please update all of the claims in the token to match this region/customer", and if so, how would I pass the information of the currently selected region and customer to the profile service/user info endpoint (without having to model each region/customer as a custom claim)?
Second of all, my worry is that this is too dynamic to be stored in the token as this WILL change multiple times over the user session. Since a user signs into the application itself, and not into each region and customer, my suggestion was that we put this logic inside of the api/resource, so that when a certain request reaches the API, we check against our permissions database or cache too see if the action the user is performing for region and customer the action is. My understanding is that OpenID Connect and OAuth should not really be used in such a way that he is suggesting, but I may be very wrong?
I've read this arcticle by leastprivilege, which seems to address the same issues that I've stated, but my system architect didn't seem as convinced..