Company specific claims

I have a scenario where a user belongs to multiple companies and the user may be an admin at one or more companies. I have a few ideas about how I could model this with JWT claims but not sure if there is a standard way of doing this kind of thing.

  1. Add the company id to the claim e.g. admin:{companyID}.
  2. Somehow pass the company id into the token request so that I only get claims that are valid for that company. Not sure of the right way to pass company id in, scopes?

For context this will be an Angular app using Universal Login hitting APIs that don’t want to lookup permissions themselves.

There may be other solutions that I have not considered.

You can use roles and permissions for this. Assign roles and permissions, and enable RBAC Core for the APIs.

Do you want a user to require multiple access tokens, one for each company he is a member of, or would that be one access token that could also be used for any of the companies he is a member of?

So when a user is admin of company1 and company2, would you want this to require one or two access tokens, one for his company1 actions, one for his company2 actions?

Based on this, I can give further advise.

Also, are all companies using the same APIs under the same URLs, or is that separate per company? If the latter, you simply use the scope parameter, otherwise not needed and you’d just base access decisions at the API on the permissions claim in the access token.

Thanks @mathiasconradt! The user will be able to select which company they are working with, after they login, so I guess it would be better to have one access token. However, I am also interested to hear about how it might work with two :slight_smile:

All requests will go to the same API no matter which company I choose. An update endpoint might look like{companyId}.

so I guess it would be better to have one access token. However, I am also interested to hear about how it might work with two

In either case:

  1. Enable RBAC for your API settings:

  1. Create “Admin - Company X” roles …

…and permissions accordingly:

and assign the permissions to the respective roles:

and assign the roles to the user(s) respectively.

When you now request an access token for such user, it will look like this, including the permissions claim containing all permissions that a user has, due to his roles:

  "iss": "",
  "sub": "google-oauth2|111416312687570061354",
  "aud": [
  "iat": 1565911095,
  "exp": 1565918279,
  "azp": "h1eN7l2S4J5U2sVV1hEBsnsXYEIVO7eb",
  "scope": "openid profile email admin:company1",  // scopes depend on the scopes you requested in the authorize request
  "permissions": [

Now, in your backend/API you would use either approach:

so I guess it would be better to have one access token.

In this case, just validate the permissions claim in the access token.

However, I am also interested to hear about how it might work with two

In this case, validate the scope claim in the access token. And make sure that when you request a token for a user for a certain company, you only add the respective scope for that particular company in the authorize request, such as admin:company1. (Ignore the permission claims in the access token, or don’t even include them there.)

Thanks again @mathiasconradt, can’t tell you how helpful this is! So in my particular case we could have thousands of companies, and the relationship between users, roles and companies will be held in a proprietary system. So I think in my case I will have to create a custom rule that is run on login. This rule will query our system to get permissions and then add them to the access token similar to your example but with company ids e.g.

"permissions": [

Then if I went the multiple token and scopes route I would have to request “admin:1234” for example. It will be the case that I won’t know which company the user works for and so which scopes to ask for until the user has logged in, however, am I right in thinking I could request addition scopes and a new token after login in the background?

With thousand of companies, my suggested approach isn’t really feasible. It works fine with a handful of companies where creating roles and permissions manually is overseeable.

Your approach as you describe it would be the way to go (both cases that you describe: one single token or multiple).

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.