I’d like to ask few questions to check if Auth0 fits my needs and how to achieve it.
Few assumptions:
I’d like to create multi tenant app lets call it app.com.
Every tenant will get own subdomain which will determinate which tenant we are talking about: my-company.app.com
One email can attend multiple tenants (but in each tenant it will be different user) . So I can be in my company tenant, I can join other organization tenant etc.
The stack is: node.js api server, SPA client, mobile client
I’d like user not left my domain / tenant subdomain at any point: I’d like to keep login form (which fit my design) on my SPA and not redirect to Auth0 domain to authenticate
Questions:
I’m planning to create one database connection per tenant - that will solve my issue with the same email in multiple tenants - but is it a right way? Maybe there is better idea?
How can achieve logging from my sub domain? Which grant type will solve that? SPA client will be first party app. Is that even possible?
What about activation links, reset password links etc - am I possible to keep it under my domain? I’m forcing that to not confuse users and redirecting them outside of my application.
I hope all my assumptions and questions are clear.
Q1. Given the constraint that you want the same email to be represented by different user (identities) in each tenant then the use of one connection per tenant seems adequate. The alternative would be a single connection and then maintain the association of users to tenants in some other way. In the general case, I don’t think you’ll have a better vs worse approach as both will have pros and cons so you might need to select between the pros you like better and/or the cons you can easily live with.
For example, on the multiple connections front you need to be aware of associated limits or use an approach where those limits would not be applicable. With a single connection you now have to manage the user to tenant association in a different way with possible more effort on your part.
You could consider an individual Auth0 tenant per each of your tenants also, but this is likely only suitable if you have very specific requirements and may be more complex.
Q2 If you don’t want to make use of the hosted login page which could simplify your implementation, but that at this time would also mean revealing a domain outside your own, then you can take a look at the recently release cross-origin authentication approach that could be suitable to your needs.
Q3. At this time and in a similar way to the use of the hosted login page if you want to use the built-in verification and reset password emails then this would mean revealing an external domain. We are aware that this is not desirable sometimes and plan to provide additional options in the future that would allow to overcome this while still using the built-in functionality. However, currently if you don’t want to expose the domain then you may need to consider disabling the built-in emails and handling the associated process in your own application (leveraging the Auth0 Management API to perform the actual user management operations).