Should I use a single Azure AD B2C tenant or multiple tenants in a SaaS app?

Question

I have a partner considering moving to AAD B2C for their SaaS app that is used by many corporate customers.

They are debating whether to have one AAD B2C tenant that is used by all customers, or whether to have separate B2C tenants for each customer. What is the best practice here and why?

A related question is regarding environments (dev/test/QA/prod): should the partner implement a spearate AAD B2C tenant for each environment, or use one B2C tenant across the environments?

Answer 1

I would suggest using one Azure AD B2C tenant for all the customers, as maintaining a separate tenant for each customer would be difficult to manage and you won't be utilizing what B2C is meant for. When using one B2C tenant, you may consider collecting Company Name during user sign-ups, if you want to later segregate or find the users based on their organization.

You may also consider federating their corporate IAM solutions like ADFS/AzureAD/Okta etc. with the B2C tenant. If you choose to go with this option, you can use this custom policy sample to implement Home Realm Discovery, which will redirect the customers to their respective IDPs for authentication, based on the domain name in their email suffix.

For the Dev and Prod environments, choose to go with separate tenants because if same tenant is used, the backend directory will be same regardless of which environment users are signing-up/signining-in for. Any testing or customization should not impact the prod directory. So, having different tenants for testing and production will be a safe choice.

Answer 2

Have different tenants.

This enforces separation and makes it easier to apply different conditional access policies, different IDP without having to jump through hoops, different MFA flows, different extension attributes etc.

It's much cleaner.

If something goes wrong, you only lose one tenant.

In terms of management, you can use DevOps .

Definitely, different Test, UAT tenants etc.

Again, deploying faulty code to Test won't affect Production.