How to include privileges in the ID token for conditional UI rendering?

Get Help
,
1

Hi there,
In our UI, we want to render certain elements based on the user’s privileges.
Using auth0 actions, I can add the user’s roles to the ID token (described here: , but not specific privileges.
Is it intended that the UI should only differentiate based on roles, or is there a recommended way to include privileges in the ID token as well?

Might be related to this: Best practice for getting client-side permissions in an SPA

Best Moritz

1 Like
3

Hi @moritz.meinhardt,

Welcome to the Auth0 Community !

You are correct when it comes to assigning permissions to roles, then adding them as custom claims in the ID Tokens using Actions.

Otherwise you can also use RBAC in order to to add specific permissions to the user profile using the Auth0 Dashboard directly or the Management. You can check you Assign Permissions to Users documentation.

Then you can use the GET /api/v2/users/{id}/permissions in order to get the Get a User’s Permissions.

Hope this helps.
Thanks,
Remus

2 Likes
4

Hi Remus,

Thanks for your response! So, I’d need an extra HTTP request to retrieve that information—got it. I have two more questions:

  1. The @auth0/auth0-angular package doesn’t support custom API calls. So, I’d need to implement my own Auth0 service for that, correct? Is there a reference implementation?
  2. We set the permissions on an organizational level. I just checked https://manage.auth0.com/api/users/[my_user]/permissions and they where empty. I have read and write permissions for specific orgs. Is there an endpoint to retrieve permissions per user per org?

Best,
Moritz

5

I found the “Get user roles assigned to an Organization member” endpoint, so retrieving roles is an option. However, since it requires the Management API, I’d rather not expose a Management API token in the UI, meaning I’d need to create an extra endpoint in my backend.

That feels like a lot of overhead, considering the permissions information is already embedded in the access_token, which I have in the UI—but shouldn’t decode there.

Is there a best practice for handling this scenario?