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!