-
In our project, we have different types of users such as customers, providers and admins. How to we segregate and manage these users
-
Our app runs on a NodeJS backend and has IOS, Android and Web apps. So should we create multiple clients on Auth0 for each platform or create a single non-interactive client
Starting from below, and assuming you’ll be leveraging OpenID Connect and OAuth2 protocols then the need for individual client application records is tightly dependent to those protocols. For example, there are different client types according to OAuth2 and just from that perspective you should separate native applications (public clients) from a regular server-side web application (confidential client)
From the information provided I would say you should have:
- an OAuth2 resource server to represent your Node.js backend surface common to all f the applications (aka an API record in Auth0 Dashboard).
- a client application for the regular server-side web application configured with the proper client type.
- a client application for each of the native application platform configured with the proper type. You could entertain the though of having just one client application for both platforms given they are both native applications, however, personally I think splitting provides more flexibility without incurring on a lot of overhead.
Have in mind that you refer to a Node.js backend that may be doing various roles according to OAuth2; for example, it can expose an API surface that is consumed either by the native apps and web application, but at the same time it can also act as the web application backend that consumes such API. There’s nothing wrong in having the same technology stack serve multiple purposes, however, even if implemented together they should stand independently from the perspective of an OAuth2 implementation.
In relation to your first question, there’s a few alternatives:
- a single connection to rule them all and perform the classification of types through user profile information.
- split the user types across connections.
- split the user types across Auth0 service domains.
You could then characterize this ordered list with:
- the higher you go, the more isolation between users you get.
- the higher you go, the more complexity you introduce in the system.
- the higher you go, the more flexibility you have.
In general, I would be inclined to go with multiple connections, however, have in mind that if it’s multiple database connections then the usage of higher level libraries like Lock may require additional custom work as by default Lock is aimed at the single database connection case.