We are attempting to have two web applications, one customer facing, and one mixed use application (both our internal team, and external customers).
Currently we have two web apps, and a corresponding tenant for each.
We’d like to move to a single tenant that functions for both applications.
In the Mixed used application, we need to differentiate between:
Internal Team
External Customers
Depending on which type of user, they will have a different experience.
In addition, we’d like to continue to programmatically assign roles/permissions to Internal Team Members.
The “Auth0 way” of doing this seems to be using Organizations, which is an enterprise only feature. We’re wary of the potential expense, and that we likely don’t need many of the other enterprise features.
Our other option seems to be noting customer vs internal team via something like metadata.
Is Organizations the best way to do this? What are other options?
I think you could further use Auth0’s Roles based Access to determine APIs’ resources access for internals vs customers.
For UI display, I think you could try (depending on technology you use for the client app), conditional components rendering / display based on custom parameters sent with the /authorize request.
The /authorize call is sent by the client app so potentially a user can modify it, but if this is just for UI differentiation, it doesn’t cause security risk.
I would like to discourage making any security decisions (access level decisions) based on user metadata as users can make changes to theirs profile data.
Hope this gives you some reference points for further investigation.
Please let us know your thoughts!
We’re currently using a mix of Auth Lock in the customer Application (Marketplace) and Universal Login in the Internal Dashboard (soon to be mixed use)
We may switch to the Universal Login for the customer app. We’d be using the SPA react library for that.
The flow for customers would be
Login to Marketplace App
Click on “My Account” in Navigation
Redirected to Dashboard App
Are you saying we could supply some custom parameters when initially authorizing?
If it’s helpful, we make use of individual permissions rather than roles in our Dashboard app for controlling access.
So, Customers would not have any of those permissions.
We also don’t provide a way for Users to edit their Auth0 User information. We have seperate profiles in our own DB.
That is correct And one of the things you can do with that query param_name:value peace of data is to access them via Actions (for example with the Post Login flow and it’s event.request property) and use them to attach some custom claims to the access / id token.
Actions, generally speaking, are here to get the login context of the user (Event object) + modify the login / access flow (API object).
Assigning permissions directly to users sounds perfectly fine.
When a user clicks on a button to access some of your API services, the authorization request sent to Auth0 will include the relevant scopes. Scopes are directly linked with your APIs permissions, and the access token received by your app will include only the ones that the user is grated. Your API service will get the access token, and the access token would contain user permissions.
The actual flow is more complicated than this, but that is the gist.
And one of the things you can do with that query param_name:value peace of data is to access them via Actions (for example with the