How to add user permissions to ID token

[aaron.hardy]

Hey community. From our single-page application, we want to know the current user’s permission so we can control access to certain sections or buttons of our app.

We’re using organizations. As you’re probably aware, permissions are assigned to roles. Users, in my understanding, can be assigned to roles within the context of organizations and can also be assigned to roles directly (outside the context of organizations). Because of this, we essentially need the union of permissions from (1) all the roles the user is assigned to within the organization the user is currently logged into as well as (2) the permissions from all roles that the user is assigned to directly (outside the context of organizations). This concept of unioning permissions from roles is basically what’s described in the RBAC doc.

I see no good way to do this. A solution I can come up with is to take the following steps within an post-login action:

• Call management.organizations.getMemberRoles to get all the groups the user is assigned to within the organization the user is logged into.
• Call management.getPermissionsInRole for each of the roles retrieved in the last step.
• Call management.getUserPermissions to get all the permissions related to the roles the user is assigned to outside the context of organizations. I assume that’s what this method is doing anyway. The docs are sparse.
• Merge all the permissions retrieved in the last two steps and add the result to a custom claim on the ID token.

This is obviously very expensive and not feasible.

Another potential solution in our case would be to just copy over the scopes or permissions (if we use the Add Permissions in the Access Token feature) from the access token to the ID token, but I don’t see any way to reference the access token scopes or permissions through actions or rules.

How are we supposed to accomplish this? If we’re not supposed to accomplish this for some security reason, can we get an explanation? This seems like it would be a very common use case.

FWIW, I’ve read the following related posts and I don’t see an answer that actually solves this issue.

The following question received no answers and doesn’t take organizations into consideration.

Enforcing permissions in our SPA

How should we determine whether a user has a specific permission in the frontend of our SPA? Let’s say we have “delete a Foo” functionality in our application which calls /delete/foo in the API, but we want to only permit users who have the “delete:foo” permission to be able to use it. If we turn on “Enable RBAC” and “Add Permissions in the Access Token” then the API can check the claims in the access token and check that the user has the “delete:foo” permission. That is great and a good start.…

The following question’s “solution” references a thread that doesn’t take organizations into consideration. Am I misunderstanding?

Including organization member' permission in the IdToken

Hi @matheus.ferreira, Thank you for your patience. After looking into this further, there are some things I would like to address. First, the permissions assigned to a user are not dependent on an Organization, but rather on the API; Meaning that they are separate from one another. Moreover, the thread you shared is the correct way to get the user’s permissions appended to the ID token. The proposed Rule will append the user’s permissions to the ID token for every user, regardless of their O…

The following question wanted permissions from not only the org the user is logged into but other orgs as well. In our case, we don’t need (or want) permissions from other orgs, but the comments seem to suggest there’s no good way of solving even our simpler requirements.

Get User permissions within an organisation

Hi @dan.woda, Unfortunately that won’t work for our use case, because the user may not be authenticated against the organisation that we’re checking the permissions for. In our app a user can be member of multiple organisations. Given that the current token will only contain permission data related to the organisation the user currently logged in to, we need a way of retrieving the users permissions for a given org that they’re attempting to access. Although ideally a single call that can give…

The following question has an answer that provides guidance on how to add a user’s permissions to the ID token, but, as far as I’m aware, doesn’t take organizations into consideration.

Accessing the permissions array in the access token

Unfortunately this is a bit confusing, I admit (already mentioned it to our documentation team): The Rules engine in Auth0 isn’t using the latest node-sdk as referenced in the API docs on Github by default. In order to enforce the latest version, you need to require it manually like below. Then the docs as on https://auth0.github.io/node-auth0/module-management.ManagementClient.html#getUserPermissions apply. function (user, context, callback) { var ManagementClient = require('auth0@2.17.0…

Thanks in advance!

[tyf]

Hey there @aaron.hardy apologize for the delayed response on this one!

@aaron.hardy

We’re using organizations. As you’re probably aware, permissions are assigned to roles. Users, in my understanding, can be assigned to roles within the context of organizations and can also be assigned to roles directly (outside the context of organizations). Because of this, we essentially need the union of permissions from (1) all the roles the user is assigned to within the organization the user is currently logged into as well as (2) the permissions from all roles that the user is assigned to directly (outside the context of organizations). This concept of unioning permissions from roles is basically what’s described in the RBAC doc .

The joining of permissions is taken care of by RBAC either outside of the context of an organization (multiple direct roles) or within the context of an organization (multiple roles assigned at org level) but not both as you’ve discovered.

What might be an option, is to rely on the permission array added to the Access Token from a login within the context of a Organization while using the management API to get a user’s direct roles and add those in a separate custom claim. You should be able to infer permissions based on the roles. This does however still require a call to the Management API:

How can I use the Management API in Actions?

Question: How can I use the Management API in Actions? Answer: There are plans to expand functionality in Actions even more in the future. Currently, the only built-in method for using the Management API from within Actions is for updating user metadata. You can use the api object to update user metadata in a pre-user-registration or post-login action: api.user.setUserMetadata(name, value) api.user.setAppMetadata(name, value) If you need to use the Management API for something other than upda…

This could be a good candidate for a feedback request as I totally understand where you are coming from.

Let us know what you think!

[aaron.hardy]

Thanks @tyf.

@tyf

What might be an option, is to rely on the permission array added to the Access Token from a login within the context of a Organization

This is the primary thing I’m trying to avoid. The frontend is supposed to treat the access token as an opaque string and shouldn’t try to decode it:

Custom claims in access token with auth0-spa-js

Welcome to the Auth0 community, @n.selikoff! The access token is meant to be sent to an API/backend, and not to be decoded by the SPA (frontend). The SPA should treat it as an opaque string. This is why the SDK does not decode the access token or provide a method to access the contents. The ID token can be used in the SPA though. As you’ve already figured out, getIdTokenClaims() method can be used to get the claims.

Respecting this, if I want to access the permissions that are on the access token, I would have to make an extra call to my server API so that the server can decode the access token and return the permissions from it.

Also, if the permissions are in the access token, it means they would be sent to the server on every request to the server when they aren’t actually needed by the server at all. They’re only needed by the SPA.

It seems like it would be much more appropriate and simpler to just add the permissions to the identity token, which is intended for the SPA to use, but I don’t see a feasible way to accomplish this with Auth0.

[tyf]

@aaron.hardy

It seems like it would be much more appropriate and simpler to just add the permissions to the identity token, which is intended for the SPA to use, but I don’t see a feasible way to accomplish this with Auth0.

Thanks for following up! Have you considered just using roles and/or even user/app metadata? While not as fine grained, you should be able to make decisions in your SPA based on the roles themselves. You might be able to add both sets of roles to an id token by way of an action - Organization context roles (event.authorization.roles) and direct roles added via the Management API. Again this is not an ideal solution (requires management API) and a bit outside of the current scope so I think a feedback request could be helpful, I’d be curious to see how much traction it would get with others.

I’ve opened this up for discussion to see if anyone else has ideas

[aaron.hardy]

Thanks @tyf. If we only add roles to the ID token, we would end up needing to map the roles to permissions within the SPA. I hope you can appreciate that having conditionals like:

canCreateTransactions = adminRole | editorRole | supportRole | ...

is less scalable than just having a permission of create:transactions provided to the SPA on the ID token. Within the SPA, we don’t actually care what the user’s roles are; we only care about what they have permission to do.

If we were forced to maintain a mapping between roles to permissions within the SPA, it would end up being identical to the mapping that already exists within Auth0, leading to maintainability issues.

[deanb]

I’m running into this exact problem as well.

@aaron.hardy have you managed to get this working with any kind of work around? I’m yet to find a work around that works or is acceptable.

[aaron.hardy]

If you just want access to the permissions the user has within the organization, then there is a feasible workaround. The workaround is to put the permissions on the access token, then open up an endpoint on your server that returns the permissions that are on the access token, then make a request to the new endpoint from your SPA to get the permissions. It’s not ideal for multiple reasons. I’m hoping the team at Auth0 can provide a way to just simply put the permissions on the identity token so we can save a request and keep permissions out of the access token since the access token is sent on every request and we only need the permissions in the SPA.