Hi, I haven’t been busing auth0 for a few years. I’m a bit rusty with my understanding
I want to do the following (typical SaaS app scenario)
Users can sign up for the product and are super admins in their org (can do everything)
They can invite further users as either admins (less rights) or employees (even lesser rights)
We want to have our own super admin access where we can monitor everything in the app, basically a dashboard like access to monitor stuff going on in the app
I’m wondering if auth0 is the right tool for this? I mean, if I use the auth0 login, where would we define the roles? Should we handle this on the backend? Or do we store the roles / scopes of which features a user can use in auth0?
If so, where? There seems to be scopes + metadata I’m a bit confused which ones are the right place for this.
Is it safe to assume that we store the roles in auth0, then via the JWT we can get the roles/scopes of the user to display the right stuff in the UI / protect routes based on their scope but as a 2nd security measure (someone could mess with the JWT?), we double-check roles on the backend? E. g. to prevent that an employee type of user can perform super admin type of actions.
I know those are a lot of questions I’m just not sure where to start
Also, role management seems to be in the paid plan only, so does that mean there’s no way to try things out on a free plan?
Thanks Karen I’m curious, for the example described above, would you recommend that every user type → global admin, super admin, admin, normal user are under their own API?
Or do I understand it correctly that the proper way to do this would be to have everything in one API and then I’ll create 4 corresponding roles under that API, and they get the scopes assigned that I have on that one API?
I would assume that you store the user’s role in Auth0, but you’ll need to be careful:
If the user is super admin in application A and admin in application B, then you would require a tenant per application, or the user comes in with both roles, as you do not connect a role with an application (client).
Alternatively, if you don’t want to have a tenant per application (since in that case, your users might have separate logins to), I would store it in the application metadata that is available for a user. Have a key for your client and then a JSON object with the role for this user and this application. Next, you could write a rule, that based on the client you are logging in to, looks at this metadata and adds the correct role in a custom claim.
/edit: I got it to work. I think what I had to do was authorize the role API to get access to the main auth0 management API. I just wanna give some quick feedback btw on your pricing:
I really wish you had roles in the free plan. It’s hard to prototype an MVP without roles included. The honest truth is right now to continuously iterate on an app I’m working on, I would have to continuously sign up with dummy accounts to test the role feature in the app. From a prototyping perspective it makes no sense to pay 20$ for something that you’re not yet using to charge customers.
I get it’s an upsell, but maybe it makes sense to allow at least a certain number of users on the free plan, e. g. 1k free role based users.
Thanks, I’m trying this out right now but I think I’m confused… So I created a role API initially… Then when I try to call that API to assign a role I get bad audience. So as I see it I have one main application (SPA) that I use for login/signup and the API for role management is a separate application (machine to machine)?
I have this code here… I authorize the role API to get a token, then I’m trying to assign the role but I get a bad audience.
It doesn’t really matter which application I use, right? I mean if my roles API is a different application from the application used for login, that doesn’t matter? I am not sure what the difference between machine to machine and single page application is.
