Multi B2B SaaS clients authentication

We have a B2B app. Meaning that we sell it to different businesses, and each business has its own users of the same domain.
For example, assume I sold my app to companyX. CompanyX has now an admin which provides access to my app to multiple (dozens) users in its organization, logging in with their email (

What would be the best practice to manage the users?
The flow is that we open the first user for the “admin” in CompanyX - and he/she invites the users in the company. They can block/delete only their company users, etc.

Logging in to our app is done from our domain, and should NOT have subdomain for each company. Login screen is and all users from multiple companies log in from there.

what would be the way to implement this? by multi db connections? by multi tenants?
I’m a bit lost in this.



Thank you for your question, I have some further clarifications I need to be able to answer,

Assuming is the seller of the app, and companyx is the customer of

  1. How would you like your customer’s administrator to manage users within companyx? Is it done via the app?
  2. What is the user experience necessary for setting up an admin in What is the user experience necessary.
  3. What kind of app is this? (mobile/web/other?)
  4. What is the total # of users? (dozens per company, how many companies?)
  5. Is federating to the identity provider of companyx an option? Is it required?
  6. Will companyx admin ever need to administer users of companyz?
  7. Any specific logging needs/password reset etc?
  8. Do you need to support social logins?
  9. Are individuals outside of any company (x,y,z) ever going to access the application?

There are many aspects to your question, and “best practice” really depends on the various details. For instance, federating in B2B scenarios is quite common and in many instances a good idea. But I wonder if that applies in your circumstance. As always you can reach out to a customer success manager at Auth0 if we need very in-depth discussions. But answers to the above would be a good place to start.

Additionally, you may also find this article quite helpful,



Thanks for your quick reply.
Following are my answers:

  1. Yes. He should be able to invite users, change role, block and delete them.
  2. Admin at can be done from Auth0. This is not client facing, so no problem to do it directly from Auth0 dashboard (if required)
  3. Web
  4. Still new, but want to be on the safe side for phase A about 25 users per company, and 50 companies.
  5. Not sure what it means…
  6. No. never.
  7. There is forget password flow, which should be initiated by each user to himself, and complete setting a new password with a link.
  8. Not immediately, but eventually yes.
  9. No.

Thanks much!

Regarding #5, “Is federating to the identity provider of companyx an option? Is it required?”

What I meant was,
Does companyX have their own identity provider, and you need to validate the’s identity against their own identity provider? For example, CompanyX users sign in using their active directory, and you need to validate the identity against their active directory (not yours).

This has some advantages in your scenario,

  • CompanyX users don’t have to remember a new password
  • You are off the hook managing the identities for CompanyX users - say user@companyX quits, you don’t have to worry about disabling their account
  • CompanyX can enforce their security policies on user@companyX

Did you get a chance to see the delegated administration link I posted earlier?


Thank Sahil,
I did read the delegated admin link - it does seem very relevant.
Per your question about federated identity - doesn’t seem like a very strong requirement now. Maybe at a later stage it will (maybe for enterprises).

One question about the delegated admin - can we customize it to have the user experience of our app and conduct all the user operations from our UI?



Regarding customizing the UX to conduct all user operations from your API - you might be able to - it depends on the requirements. Auth0 comes with management APIs that pretty much let you do everything from the APIs that can be done via the dashboard.

The specific architecture and structure of your APIs calling Auth0 APIs would most likely be very specific to your project and needs. Auth0 does have a professional services offering which allows us to engage at a much deeper level specific to your project.

However to get started with the APIs, you may find the below link useful,


Hello Sahil

It seems I have a case similar to Guy’s
After reading the Delegated Admin page it seems it will not be a good fit because it handle all users.
So Admin of company x will see also users of company y.
Did I understand correct?


@eperi I think you could use the various hooks to help apply restrictions on which users someone is allowed to see:

Hello, I’m not sure it’s good enough. It need to support different companies not just different department. i’ll need to play with it.
I got this link, How To Use Auth0 To Manage Your Multi-Tenant Application that seems to be what I am looking for.
please note that the sample link in the article is broken (

@eperi without knowing how you’ve implemented everything the example I provided can be used to model companies. The department metaphor was a for instance, but could be used to model companies. Any criteria could be used to filter users.