Assign roles to m2m clients

Hi, from the UI I can see it’s possible to assign permissions to m2m clients.

However, I cannot seem to assign roles (as far as I can see). Is there a way to associate a role to a m2m client?

There seems to be another other threads asking this question, but no public or documented answer:

Hi @lyndon.fawcett

I don’t think there is an easy way to do this. What is the use case?

John

Hi @john.gateley, thanks for the reply.

My use case is that I have a single API Gateway which is accessed by both human users and machines.

Both humans and machines need to have restricted access to the endpoints and resources that they need to access. I was planning on using a combination of Roles and Permissions to achieve this but noticed that they are only available for users.

I’m trying to support multi-tenancy within my application.

I was thinking that I could have generic permissions for the application (read:config, write:config) and then use the role name to capture the tenant context e.g. a role name: tenant1_config_admin.

I don’t want to have to resign in for each tenant, I want the user to be able to seamlessly swap between tenants without getting a new token.

Reading Multi-Tenant Applications Best Practices it suggests that for my use case to use app_metadata to achieve this, however that means that the scopes defined in Auth0 work across all tenants for a single user, which is not desired. For example, a user may be an admin in one tenant and only a user in another.

Heres example output of an access token payload on the above:

scopes: "config:r areas:rw"
permissions: [
   "config:r",
   "areas:rw"
],
tenants: [
   tenant1,
   tenant2
] 

The only solution that I can see to this is by putting everything, both tenants and roles/permissions in the app_metadata and use rules and hooks to put this into the access token. This works but feels clunky. Also, the client_metadata for m2m seems limited to a key-value pair list, which limits how it can be used (not a json object which can easily define a struct with tenants: roles: and permissions, though can be built up in the hook)

Example output of the above in an access token:

scopes: ""
permissions: {}
tenants: [
   tenant1: [
     "config:r"
   ]
   tenant2: [
     "areas:rw"
   ]
]

Any further guidance on this use case would be greatly appreciated!

Hi @lyndon.fawcett

This is complex. Multi-tenancy is complex. For this, I suggest our professional services.
It requires some time to completely understand what you are trying to achieve, then architect the system.

John

1 Like

Hi @john.gateley ,

I suppose I was looking for an off the shelf answer for this use case. It’s good to be aware that there isn’t one. Thanks :+1:

Lyndon

Sometimes it’s just not that obvious Lyndon but we’re happy to help!

1 Like