We’re developing an application for managing assets of organizations. An organization (which will use our service) can create an organization in our application and start adding/managing assets. A user in our application can be a member of multiple organizations with roles and permissions that are different for each organizations he’s a member in based on his involvement/relationship with each organization (organization is a context for the roles and permissions). Our application provides APIs (RESTful APIs) for different type of clients, so Auth0 will secure our APIs and our clients assets (resources).
Based on Auth0 documentation, the token should have only coarse-grained roles and permissions to avoid have large payload.
What is the best way, to implement this? should we use Auth0 for authentication only and handle authorization in out application?
I know adding all the roles and permissions, of each organization the user is member in, to the token is not right and practical.
@asahaf
This is a lot to tackle in one post, but we’ll do what we can .
It sounds like you will probably have a common database where all of your users authenticate since one user can access multiple organizations. Then you will have to distinguish different permissions in a user’s app_metadata for each different organization so they can have different roles/permissions for each application.
If you set it up this way, I would recommend authorizing a user for a particular organization. One way that you can accomplish what you are looking for would be to have a different API for each organization.
The advantage of this, is that you can get a new access_token for each org1. Therefore, in your application, when you send a request to /authorize, you can add audience to your request. This audience can then be found in your rule at context.request.query.audience. You can use that audience then to pull only the permissions you are allowing from the app_metadata for this person, for that specific org and add them as a custom claim to the access_token or use them to set context.accessToken.scope to the right scopes for this org.
Assuming you won’t have one client calling out to many different orgs in a single instance, this should be a fairly smooth way to handle this interaction. This can get a little tricky if you are using refresh tokens instead of redirecting to authorize for a new access_token because you don’t have access to the audience in the rule, but in the case of a refresh token, it should be specific to the audience already and should only give you back the same scopes you had before by default. Just keep that in mind in the rules when writing them. If someone’s access changes, you’ll have to revoke their refresh tokens.
.