Managing multiple sites (similar to slack) the most efficient way?

[andreas1]

I have been building and running an online community for a few months, we’re now planning to launch another online community, separate on a different domain. Moving forward we want to take this even one step further and have a platform that lets anyone create their own online community.

Right now auth0 works well since its only for one domain, but let’s say we go to two communities on different domains, do we set up 2 auth0’s or two clients? This still works with only 2 communities, however imagine we will offer the platform, no we may have 10 new communities created a day with each their own domain / login.

I would actually prefer to be all easily maintained under one account / client but being able to filter for analytics purposes, however there’s one issue I am not sure about: If you keep everything under one client, how do you make sure the authentication changes? E. g. “Product Cafe needs your permission to login” or “CPA Ninja needs your permission to login” via google auth. We want to offer a good user experience for any community we launch, so serving some generic name such as “CommunityBuilder needs your permission to login” would confuse and maybe even scare certain users.

How would one go about doing this with auth0? Multiple accounts sounds unlikely, simply already due to operations hell. Do we use multiple clients and it can be automated to generate them? Or is there some other way that works in an automatic way?

The other things that’s not clear is the pricing. I understand the free tier of 7000 free active users, however when I then look at the developer plan of 1000 users at 185 dollars this basically looks like a huge downgrade, so I wonder if there’s an option to just pay but not as a developer plan? What happens after I reach over 7000 active users? Do I need to switch to the developer plan?

[richard.dowinton]

There are three common approaches to dealing with multi-tenant applications in Auth0: one Auth0 client per application tenant, one Auth0 tenant per application tenant, and one shared client per Auth0 tenant.

In your case, either of the following options makes sense:

1. One Auth0 client per community.
2. One shared Auth0 client for all communities.

Which you choose depends on a number of factors.

If you need each community to have separate user bases and thus use separate connections, having an Auth0 client per community may be more suitable.

Should you go for this option, you can create the clients via dynamic client registration and map the relevant configuration to the community in your application.

The main drawback of this is that it requires you to manage multiple client configurations. You will need to map the community the user is trying to log into to the relevant client configuration and load it accordingly.

This is more of a problem for mobile applications which are typically deployed with a static client configuration. In such cases it would likely be necessary to query some kind of API that would provide the client configuration for a given community name.

Another consideration is whether your communities will have a single shared user base or whether they will each have their own isolated from the others. In other words, do you need a single Auth0 connection to use across all communities or will each community need its own connection?

Regarding pricing, you will need to upgrade once you reach over 7000 active users.

Although the developer pro plan is $185 a month for 1000 users, unless there are specific features you need that aren’t in the standard developer plan, the latter would be more suitable and only costs $13 a month for 1000 users.

Of course, if you were to upgrade upon reaching 7000 users, you would need to pay $200 per month for 10000 users on the standard developer plan.

[andreas1]

Hi, thanks for the feedback Some things I noticed while trying out multiple clients:

1. No way to distinguish users, I guess only way to do this is pushing the client’s name into the user profile?
2. It looks like it’s not possible to use different social settings, right?

[geoffberger]

@richard.dowinton thank you for providing these approaches.

Regarding going with a single shared user base, do you have any advice or thoughts as to how to separate users within Auth0? For example, separating by app_metadata or some other preferred way.

Thanks!