Looking at this
I input my user id and use my company’s standard auth0 domain and I get “404 page not found” but if I use our custom domain I get just “Not found” as a response, I don’t have much else to specify that I can think of, please let me know if I need to clarify. Can someone expand on this article about getting user roles?
Edit: I come to find out that this is a part of the management API, is this the only way to get user roles is with the management API? I would think it should be a part of the decoded jwt token, is there a reason it’s not? I read somewhere that it’s common practice to infer the users role based on their permissions but I don’t understand why that’s the case.
I got a notification because you linked to my question. Even though you marked your question as answered in your second post your asking for reasoning behind it and I can offer you my 2 cents.
Permissions are included on the token, but roles are not. If you chose to do so you can add roles yourself through custom logic, but what does that get you?
Roles are a way of grouping permissions, if you have a total of 3 permissions in your application, hardly worth the trouble, but think of a system with hundreds of permissions and parts of the app clearly segregated by those. From a user management point of view it makes perfect sense to group them into roles as it makes life easier. Ex. “CRM User”, “Invoice Viewer”, “Invoice Admin”.
You API will not/should not check for roles, but rather individual permissions.
On the other hand, on the frontend, you might have a case of reasoning around roles, maybe like “okay, if the user has invoice viewer role, I’m gonna show this whole menu section called invoice”. But that’s usually also tied to a permission belonging to that role anyways, so no real benefit in fiddling with roles. So yeah, reducing redundancy sounds about right.
In your token, you should really care about individual permissions, use roles for managing and grouping, not asserting.