Permissions/Roles Design Question

It is the responsibility of the Resource Server (API) to provide access control. This is particularly important when it comes to fine-grained access control for the reasons you have pointed out, this can get pretty gnarly to try to do in the Authorization Service (your Auth0 tenant) itself for the concerns you already mentioned.

That said, there are things that your Authorization Service can help with, but you need to consider a couple of things when deciding how much data to put in the user’s app_metadata:

  1. How often is this data going to change?
    If this data is going to change frequently, and you want instant updates to the information (as in, someone logs into the app and gives permission for another user to access their data, how soon do you want that to take effect?), then you would want to store that in the API’s data store rather than in the Access token which only changes when it expires.
    You also need to consider rate limits on your Management API. If you will be making a lot of calls to adjust this fine grained information, you need to make sure that isn’t going to push you over rate limits.
  2. Is this permission information needed outside of the API itself?
    Are there multiple APIs that all share this data, and no one API owns it? If so, then put the information in the access token, if not, then let the API own the data itself.
  3. How large is this data?
    Just from a practical perspective, there are limits to the size of an access token and the size of your user metadata. If this could expand to a lot of combinations, then it could get unruly to expect all of the data to be in the access token.

You can certainly use rules to grab information from app_metadata and create custom claims, and the metadata is open ended (it is just JSON), so you could store some of this information in app_metadata and use a rule to put it in the token. But you need to consider the impacts of that and whether that is the right approach. Once you start talking about individual users having N-type access to M-number of users, that can get to be a complex and large enough matrix that Auth0 metadata may not be fit to address.

1 Like