This question is essentially a follow-up to THIS ONE but that is locked so I had to create a new one.
So the problem is pretty simple. The response from a successful authorization contains an accessToken, which has in it all of the permissions that the user has for that specific API only. It also contains an idToken, which is the only thing that the UI should actually be looking at. Neither are encrypted or anything. There’s nothing stopping the UI from reading the permissions straight out of the accessToken except advice that we shouldn’t.
So the suggested solution is to make a rule which makes a call to the Auth0 API to get the user’s permissions and set them as a custom claim in the idToken. The list of permissions returned, however, are ALL permissions for every API that the user has permissions for, not just the one that the user is being authenticated for.
So the suggested way to fix that (as of last October) is to cross-reference this list of all permissions the user has with the list of all permissions the API that the user is authenticating for has.
So I need to know which API that is. Okay. Well I know the ID of that API within the rule because it’s in context.request.query.audience, so I could figure out how to get all permissions for that API ID, or I could filter the permissions by that API ID to avoid making another call to the Auth0 API.
Except if the rule is being run as a redirect-callback, then context.request.query.audience has been removed. So I’d have to add it back in as an additional query parameter when I call /continue. In order to do that, I’d have to put the API ID in the URL that I redirect to.
All that, or make an additional call to my API to ask it for the permissions that I’m giving it.
This seems like a lot of workaround and inefficiency just to tell the front-end the same exact permissions that are already available right there in the accessToken. Is there a simpler way? If not, why?