Multi-tenant or no tenant? SaaS company B2B onboarding standard

Nadiem 0 Reputation points

Dear fellow devs,

Currently, we're creating a SaaS application, where we would like to onboard bigger companies using their MS AAD Tenants.

Auth0 is used for the users to sign on and connect to the companies MS AAD Tenant. We're indecisive about the architectural structure that should lay behind the Microsoft AAD tenant, and the Auth0 tenant.

What would we want to achieve:

  • Company logins are displayed on a subdomain as in
    • etc.
  • Only display 1 login button per subdomain
  • Connect the companies tenants to our Auth0 login system (either to our ms tenant or only to Auth0 - the current problem)

We have set up our own MS AAD single tenant and connected it to Auth0. We are unsure if we would actually need this tenant to be a multi-tenant or if we should ask the onboarding companies for their tenant specific information (tenant-id, secret etc.) to be able to connect them to Auth0.

Furthermore, we are trying to figure out what the correct architecture would be and if we would need an MS AAD multi-tenant for the other companies to connect their tenant to, or if we would go with a direct option in which the companies would give us their tenant information, and we would immediately connect them to our Auth0 tenant.

Any advice will be appreciated!


To summarize, the main problem for the MS support team:

In Auth0, you can add different MS AAD tenants to an Auth0 tenant. This won't result in different domains, therefore we would need to create multiple Auth0 tenants. Each Auth0 tenant would be linked to either OUR own MS AAD multi-tenant or to an onboarding companies MS AAD tenant (when directly connecting to a companies MS AAD tenant, we're eliminating the need of having our own tenant maintenance etc).

We are unsure if we would actually need an MS tenant and if so, if this tenant should be a multi-tenant or if we should ask the onboarding companies for their tenant specific information (tenant-id, secret etc.) to be able to connect them to Auth0 and eliminate the need of our own MS tenant.

Yesterday I had a call with MS, in which they thought creating a multi-tenant would be the easiest solution for the problem, but it's still not clear why and how. For now, they redirected me to the application department.

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
20,446 questions
{count} votes

1 answer

Sort by: Most helpful
  1. Nadiem 0 Reputation points

    Within Auth0, there is the option to have a different login experience for different companies, this is only possible through organizations. Then we still won't be able to have multiple subdomains..., (organizations). Using organizations is only possible when you're not using the Auth0 management API. Which we are using. Therefore, the solution to create a SaaS product, with multiple subdomains, where companies can log in over their MS AAD tenant on their own subdomain is as follows:

    • I've created a multiple AAD tenant application.
    • I've created one Auth0 tenant per subdomain.
    • Every single Auth0 tenant will be connected to our own multiple AAD tenant application
    • Within every single Auth0 tenant, you can add rules (in the future actions), in here we can check if the user trying to log in has a matching tenant ID with the allowed tenant ID's. If the user's tenant ID is from a different company, it won't be on our whitelist.
      The rules within the auth0 pipeline look like this for now.
    function (user, context, callback) {  		
    	var ownAADTenantID = 'lotsofnumbersandletters';      
    	var companyAADTenantID = 'lotsofnumbersandletters';    
    	//authorized Azure AD tenants.        
    	var whitelist = [ ownAADTenantID, companyAADTenantID ]; 
    	var userHasAccess = whitelist.some(
    		function (tenantId) {          	  
    			return tenantId === user.tenantid;        
    	if (!userHasAccess) {        
    		return callback(new UnauthorizedError('Access denied.'));      
    	return callback(null, user, context);
    • The rules will be depreciated in November 2024, I hope Auth0 will have a solution to use the actions by then....
    0 comments No comments