Microsoft Entra External ID is part of Microsoft Entra and is designed to address scenarios that involve external access to an organization’s applications and services. So, what constitutes external access? External access is access by end users that are outside of your organization, that is, typically by end users that are not employees of the company. In this short article, I attempt to demystify and explain what Microsoft Entra External ID is designed for, and how to use it for your scenario.
Importantly, there are two tenant configurations as part of Microsoft Entra External ID:
- Workforce tenant configuration
- External tenant configuration
Both are directories/tenants, containing user accounts, application registrations, amongst other objects. The challenge, however, is that when you create a tenant/directory, you must choose which configuration you need up-front. In theory, it should be simple to choose the most appropriate configuration based on your scenario, but as always, the devil will be in the details.
Here is a simple flowchart that shows the options available:
Importantly, you have to choose the tenant configuration up-front, and you cannot change it later. So how do you choose which tenant flavor you need? What questions should you be asking?
Are the end users performing work on behalf of themselves, or are they performing work on behalf of my business? If the external end users are doing work on your behalf and/or you are paying them for it, that looks like a good candidate for the workforce tenant, since the primary scenario is business collaboration. However, if you have end users that are paying you money for products or services, then that sounds like a good candidate for an external tenant configuration. Therefore, if you have an Azure Active Directory (AAD) B2C tenant, then it’s rather clear you need to migrate to the external tenant configuration when you are able to do so (i.e. when it has all the features and functionality you require).
Essentially, the workforce tenant is for workforce scenarios, where you collaborate with business partners or other vendors. In the workforce tenant, these are known as guests. You can collaborate with individuals, or other companies. However, an external tenant was designed for customer identity and access management (CIAM) scenarios, so it doesn’t make much sense to focus on guests because almost all the user accounts in that external tenant configuration would be considered “guests”. You would choose the external tenant configuration if you are developing any type of application that is designed to be accessed by customers, whether these customers are individual consumers or business customers, sometimes also known as Business-to-Business (B2B) CIAM. So, in short, if they pay your business money, they are customers and belong in the external tenant.
Now, is it really this straightforward to choose the most appropriate tenant configuration? In theory, yes, but in practice, it’s a bit more nuanced.
In fact, it is possible to use a tenant in the workforce configuration for CIAM use cases; perhaps because an external tenant does not yet have all the capability that a workforce tenant does. For example, a workforce tenant has Entra application proxy to allow secure remote access to the enterprise’s private applications, but an external tenant doesn’t have this capability (yet). In theory, if you are building a SaaS application for your customers or need to expose a legacy on-premises application to your customers over the Internet, you should be leveraging the external tenant configuration. However, it’s not always going to work well, based on current features and limitations of the product. Nonetheless, Microsoft is constantly updating both tenant flavors with more features and functionality.
Also consider which specific applications your end users have to access: SharePoint Online (SPO), Teams, Power Apps, Power Pages, on-premises legacy line-of-business (LOB) apps, 3rd party software as a service (SaaS) apps, or simply your custom developed SaaS or mobile apps? This can have an influence over which tenant configuration you select today. My hope is that although the choice of which tenant flavor to use is not always clear at the moment due to lacking features, my expectation is that this becomes less “cloudy” over time as more capabilities emerge for both workforce collaboration and customer scenarios, since both are built on a common Microsoft Entra identity platform.
Choosing a tenant configuration is a critical design decision that needs to be carefully considered. Unfortunately, you can’t simply switch the tenant configuration after it is created.
My own personal opinion is that it would have made more sense to have only a single tenant type, and allow businesses to choose what it is used for, whether for workforce or customer scenarios. Most organizations would still decide to have separate tenant instances, and that makes sense.
However, now that we have two tenant configurations to choose from up-front, it’s more complex, because there are currently feature differences between them that can influence your decision. You may end up choosing the best tenant configuration in theory based on your scenario, only to find out much later that it doesn’t support your exact use case in practice.
My hope is that in the future choosing a tenant configuration will be strictly based on your business scenario, which is the ultimate goal, rather than based on technical functionality that is missing in your preferred and most appropriate tenant flavor or other such technical limitations.