Purpose of setting user roles when fine-grained access is needed

When configuring user roles in Auth0, whether by the management API or the dashboard, it’s not possible to assign some type of context for the role.

For example, if my application has the concept of “workspaces” and a user can access multiple workspaces, scopes (and by extension roles) are only relevant within a workspace.

A scope of workspace:update or role of Workspace Admin is meaningless without referencing a specific workspace. So should roles not be used for this use case? I understand that the final permission should be determined from a combination of access token grants and internal API authorization rules (as explained extremely well in this post). My question is then, what is the purpose of roles and scopes for users in Auth0?

Our team is facing something similar to what you call “workspaces”. We have adopted roles and permissions, and it works great for defining CRUD actions for “fixed” topics in our application (like labels and messages). We are still debating how to “solve” the “workspace” challenge.

I think we will use permissions like workspace:create and workspace:update for high-level action like creating workspaces, and “adding” users to the workspaces. But the information about what workspaces are related to a given user is something we will store in our db (maybe in app_metadata).

When designing your solution, I think you should consider how rapid users are re-assigned workspaces, the total number of users in a given workspace etc. This potentially rapid changing relations are not well suited for permissions/roles.

Yeah, our solution will be implementing RBAC ourselves within our application.

We’ll have a table that looks roughly like:

CREATE TABLE workspace_user (
  workspace_id uuid NOT NULL REFERENCES workspace(id),
  user_id uuid NOT NULL REFERENCES "user"(id),
  role workspace_role NOT NULL
);

Then for a given user and a certain API query, we will look at the relevant roles and determine if they have access. Roles will be a collection of scopes and scopes will be defined internally as well. This way, we’ll provide workspace administrators to change the roles of their workspace users from our application.

I was hoping to leverage Auth0 for this so that our non-technical ops people could manage that in the dashboard, but it looks like that’s no possible as the feature is currently designed.

All that being said, I’d love to understand a use case for which the current feature set in Auth0 is the right fit.

Hey @migueloller @alexab,

I reached out to some folks about this topic as it seems like a possible opportunity. Hopefully we can get some discussion from the team, or at least some feedback I can pass along. Feel free to add any more detail you feel is relevant.

Best,
Dan

That sounds great! Would love to hear what their thoughts are about the current state of things and how it could be different in the future.