Well, I haven't find anywhere any guideline about this subject, so here is my case.
I am starting to create a platform of APIs and it's based on JWT tokens generated by an IdentityServer4 server. And I expect to have 75-100 APIs at least.
By trying to follow the specification, I would have to create 75 ApiResource objects and each with a set of scopes (permissions), so we would be talking about 300+ scopes. Defining that into a file although is cumbersome, it is doable.
Now, when we go to the user workflow, the client (web application), in theory, would have to request all the claims any user may need (e.g. 150 scopes), so it is a very large request. And if the user has many roles linked (admin, user, sysadmin), then the token could potentially contain all of those scopes, which is a very large token and that could be problematic.
How would you recommend this be solved? I see several options:
- Make more use of the user-endpoint with the hit in performance and stability. This way the token is smaller but eventually I would still need to call the OIDC server to obtain more information about the user.
- Reduce the number of scopes to one per Api, but in the end there could be 75 Apis, so it is still a large number.
- Reduce the number of scopes to be 1-5 for all Apis, so it is more of a group than a single API. This comes with the reduced effectiveness in the security (or will it really be a management hell to have everything mapped and configured?).