How to handle different user types?

[nmck]

We have several apps/web apps, that have different user ‘audiences’:

Internal users - Admin dashboard type apps
Partner users - Partner apps used to access some of our services.
Customer users - customer facing apps.

Each app talks to our API, which is run on node.js/express.

How should we separate these different user ‘audiences’ in order to identify them within each app?

Example 1: A ‘customer’ user visits a ‘partner’ web app. If they try to login, they should be redirected and notified they are not authorized to access the app.

Example 2: An ‘internal’ user should be able to access an ‘internal’ app and any ‘customer’ apps, but not a ‘partner’ app.

[markd]

Hello @nmck,

Welcome to the Community!

You can leverage the authorization features that Auth0 offers, or roll your own access control methodology by including roles and / or attributes in the user’s app_metadata. For example, a customer might have:

"app_metadata": {
  "roles": [
    "customer"
  ]
}

You can then create a rule to allow or deny access to a given app based on the user’s roles, or your can create a rule to add the user’s roles to their id_token which is passed to your app and your app makes access decisions.

I hope this helps.

[nmck]

Hi @markd,

Thanks for the great response, that clears a lot of things up.

I did see in the documentation that a possible way to separate users is to use different tenants.

In this example, would it be worth having a separate tenant for customer users, and a tenant for internal/partner users?

As all of the users will be accessing the same API, will the separate tenants introduce complications when setting user permissions on the API?

[markd]

Just a personal opinion:

I would avoid multiple tenants if possible, unless you have two very distinct sets of users and applications and you are certain those groups will never ‘cross paths’. E.g., an internal user will never access a customer app, or if they do they will use a separate set of credentials.

IMO multiple tenants makes things unnecessarily complicated where some manner of role / attribute / policy-based access control using profile attributes will usually do what you want w/o the complication of multiple tenants.

Another good reason for multiple tenants could be regulatory requirements: Not sure this is a thing anywhere today but it is conceivable that regulations could demand the delineation provided only by separate tenants.

[markd]

I’ll signal boost this related blog post which is, in typical Auth0 style, very good:

Dynamic Authorization with GraphQL and Rules