I have another architectural question regarding SuperTokens and its Core. How suitable is the solution for use by multiple services? I would like to use SuperTokens to manage users which are authenticated into multiple apps, and plan on using the UserMetadata recipe as well as UserRoles recipe to store permissions, roles and groups (using the metadata as unfortunately groups aren't part of the UserRoles recipe). My question is particularly regarding some features like initializing recipes and creating all the roles and permissions - from what I can tell I just have to call an initialization method in my service and create all those beforehand to avoid issues later, but if I have to do this in every service just to ensure that the data really exists it seems like this isn't the best approach. How would you go about managing users that are accessed by different apps, and was SuperTokens built for this use-case?

Hey @Dan6erbond

Thanks! And when those apps connect to the SuperTokens core, will I have to initialize all the recipes everywhere? Or would it be sufficient to initialize them once in my "main" or central app and have it take over? From my understanding the initialization of those recipes allows SuperTokens to create related tables and such, correct? Also, is there any plan to add groups to the UserRoles recipe? It seems like a missed opportunity since it would be just another field that would make user grouping and querying easier.

> will I have to initialize all the recipes everywhere? Not really. Only the recipes that you intend to use in that backend. If you have one backend for actual auth, then all recipes there, but if other backend just use the session management feature and roles feature, then just those two.

> If you have one backend for actual auth, This is the case, and admittedly I'd like to handle as much as possible over that backend, as it will centralize the user management so I can modify the solution easily, but as you might expect in situations like simply getting some user data or the roles it would be great if I could do that directly in the app. > but if other backend just use the session management feature and roles feature, then just those two. That's great. In particular the

ThirdPartyEmailPassword

recipe is a huge amount of boilerplate code to setup, but if I only have to initialize that in the backend that handles sign-up/sign-in it will make things much easier! > Creation of the tables happens on core start. The recipes are initialised so that the SDK knows which APIs to expose from the middleware Oh, gotcha. Interesting. Then another question: How can I find out which APIs the middleware does expose? Those might be useful to ensure as much as possible happens over the main authentication server. > What does groups really mean? We have users which can be mapped to an array of roles, and each role can be mapped to an array of permissions. So where does groups fit into this? Well, in a standard directory like LDAP you have groups which could be tenants, organizational units, etc. while roles correspond more to the user's function within that unit. As I mentioned I've already solved the issue somewhat by using the

UserMetadata

recipe to store the user's group, but it would be nice if that was part of the

UserRoles

recipe as that seems to be handling the user directory overall. Additionally, I'm not sure what the technical limitations exactly are, but being able to query users by

UserMetadata

fields I feel would be an awesome addition, and at least in MongoDB and PostgreSQL that should be possible. I know SuperTokens also supports MySQL, so it might require a solution where MySQL reduces performance, but for querying users by certain value I'd find that extremely useful.

> This is the case, and admittedly I'd like to handle as much as possible over that backend, as it will centralize the user management so I can modify the solution easily, but as you might expect in situations like simply getting some user data or the roles it would be great if I could do that directly in the app. In that case, you need to do session.init and userroles.init in those other backend > but if I only have to initialize that in the backend that handles sign-up/sign-in it will make things much easier! Yes - exactly. > How can I find out which APIs the middleware does expose? Those might be useful to ensure as much as possible happens over the main authentication server. https://app.swaggerhub.com/apis/supertokens/FDI > Well, in a standard directory like LDAP you have groups which could be tenants, organizational units, etc. while roles correspond more to the user's function within that unit. As I mentioned I've already solved the issue somewhat by using the UserMetadata recipe to store the user's group, but it would be nice if that was part of the UserRoles recipe as that seems to be handling the user directory overall. I see. Makes sense. Will probably add this extra layer as part of organisations / multi tenancy feature then. > Additionally, I'm not sure what the technical limitations exactly are, but being able to query users by UserMetadata fields I feel would be an awesome addition, and at least in MongoDB and PostgreSQL that should be possible. I know SuperTokens also supports MySQL, so it might require a solution where MySQL reduces performance, but for querying users by certain value I'd find that extremely useful. Hmmm. We store the actual JSON in the db as a TEXT field. So not sure how we would go about this without using MongoDB only.

> I see. Makes sense. Will probably add this extra layer as part of organisations / multi tenancy feature then. Is there an issue for this feature that I can follow?

> Is there an issue for this feature that I can follow? Not yet. Feel free to open an issue