Hi,
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 (username@companyx.com).
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 app.mycompany.com 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.
How would you like your customer’s administrator to manage users within companyx? Is it done via the app?
What is the user experience necessary for setting up an admin in mycompany.com? What is the user experience necessary.
What kind of app is this? (mobile/web/other?)
What is the total # of users? (dozens per company, how many companies?)
Is federating to the identity provider of companyx an option? Is it required?
Will companyx admin ever need to administer users of companyz?
Any specific logging needs/password reset etc?
Do you need to support social logins?
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.
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 user@companyX.com’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,
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 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.