We are building a multi-tenant platform using a microservices architecture. There is an SPA for the front end, and many APIs behind an API gateway that serve as the backend.
We chose to store permissions in the access token, to avoid having to check them in every API call. So if an API receives a request, and the token is verified (signature and expiration), it assumes that the user has the permissions stored in the token.
The issue that we are facing concerns permission changes. If I add or remove a role from a user, it will not take effect until the client app refreshes the token using silent authentication.
We thought about setting a short expiration time and refresh the token every 10 minutes or so, but we would rather not have to wait so long for permission changes to be applied.
Another alternative would be send a signal to the SPA that would cause it to refresh the token right away. This signal could be sent on any API call, or by periodically polling a dedicated endpoint.
Is there a recommended way to deal with this issue?
As you probably imagine, there is no “right” answer for this, and it’s most likely a question of compromises and complexity.
If you need your permissions to take effect immediately after being changed, then the approach of putting the information in the token will always get in the way.
If you need a quick response to changes, you might want to consider an approach where permissions are evaluated in the API directly (as opposed to putting permissions in the token), with some caching logic to optimize performance.
If you prefer to keep the permissions in the tokens and somehow notify the involved parties about changes, I think I would put a little more logic on the API side. Your permissions systems could notify your API about changes (“permissions for user XXX changed at time YYY”). The API can use that information and return 401 when receiving tokens for that user issued previous to the informed date/time.
Application should have logic to refresh the tokens when receiving a 401, without really being concerned about the actual cause of the current tokens no longer being valid.
By keeping the notification loop between servers (your API and the permissions management system) and having the SPAs simply react to responses from the API, the separation of concerns sounds cleaner.
In any case, I’m just thinking out loud here, and there could be other approaches better suited for your scenario.
lets say we have three users john , mike and bruce . john and mike have been assigned with super admin role whose permission has changed . so how can i get to know that super admin role has 2 users so i only refresh john and mike access token rather then refreshing all users token
You could invalidate all tokens that have a “super admin” role and are issued prior to a specific date/time (when the permissions for that role were changed). This architecture means that, when receiving a token, you should be able to know what roles are assigned to it (either by listing the roles on the token, or by getting the roles by other means). But, again, I want to be very clear on this: there’s no “right” answer. You will find that the more stringent your requirements are in terms of how quickly you need to react, the more complex or less performant your solution will be.
we have roles and permissions defined in authorization extension
The authorization extension is definitely not designed to be queried on every API request, nor it has any built-in mechanism to notify about changes in permissions. It was built with the idea of calculating effective permissions during log in (when a rule executes), and putting those permissions (or roles) in the issued tokens.
If you need immediate reaction to changes in the authorization data, you might want to consider taking that authorization data closer to the API, so that you can evaluate permissions on every API request.