Very often, I am involved in discussion related to Azure AD and Identify and Access Management. A common topic is related to what we should use – Azure B2C or B2B and what is the best option for the given context.
Let’s try to identify what are the main differences between and what are the limitations of the two options that we have available inside Azure AD.
Azure AD B2C
Azure AD B2C (Business2Customers) is for solutions that have a front-end and interaction with users. It enables us to have an identity system that supports users to sign-in using their own identity or identity created inside Azure B2C. Users can use their personal Facebook, Google, LinkedIn or Amazon account to log-in inside your application.
Azure AD B2B
Azure AD B2B (Business2Business) has a different purpose in comparison with B2C. The primary purpose of it is when customers want to share resources (e.g. files, Azure resources, Office 365 content) with external users. B2B involves federation between the customer AD tenant and customers tenants. It requires that the customer tenant be available from the internet.
We should note that even if users receive an invitation on their email account, at the moment when they accept the request, a new identity is created inside Azure AD. In comparison with Azure AD B2C, when the identity is persisted inside the identity provider (e.g. Facebook) and only specific information is shared with the Azure AD.
Features
(1) User Management
Inside B2B, the users are managed inside Azure AD, but they are marked differently. This enables the AD administrator to provide external users access to resources (e.g. files). In comparison, B2C users are managed separately, and they cannot receive rights to access resources.
(2) Single Sign-On (SSO)
B2B has full support for SSO, including Office365 and any other application integrated with Azure AD (including on-premises ones like Workday).
In contrast, the SSO support for B2C is limited, and the application owner owns it. There is no support to use SSO when you B2C users try to access Office365 or other Microsofts services. This happens because the B2C users are not managed in the same ‘pool’ as the AD users.
(3) Supported identities
Azure AD B2B has support for work and school accounts, together with federated accounts. All identities are stored in the same locations and can be managed from one central location.
In contrast, B2C supports only consumer users with local application accounts or with social identities that are federated with B2C. Even for a local account inside B2C, the accounts are not stored inside the AD pool. This is why sharing Microsoft resources (e.g. Sharepoint resources) is not possible in the B2C context.
(4) User lifecycle
The owner fully manages the lifecycle of identities inside B2B. For federated accounts, the user management is done by the partner identity provider; the B2B owner can specify only what resources can be accessed (e.g. user password management is not done in the Azure AD B2B pool, is done inside the identity provider pool).
In the B2C scenario, user management is done entirely by the customer, that has full control over it (related to user activity inside his application).
Azure AD B2B Insights
If you use Premium tier, for each user inside AD, you can connect up to 5 users from a federated identity provider.
Keep in mind that Microsoft accounts are also supported inside B2B. For non-AD or Microsoft accounts, the users receive an invitation on their personal account that will invite them to create a Microsoft account for it. In essence, the user needs to manage the account separately (including a separate password). The new Microsoft account that it is created in this case will be used when they sign-in, even if they use their personal email account (user@gmail.com).
Azure AD B2C Insights
When you use Azure AD B2C, there is a nice feature that allows us to collect additional user information after a specific time or after a specific number of log-ins. For example, after five log-ins, the user might be asked what car manufacturers he prefers. In this way, you can improve the user profile without requesting all this information during the registration phase. As for Azure AD B2B, the Azure AD B2C does not require your application to run inside Azure. Your application can be hosted on-premises or on another cloud provider, like AWS.
When to use it?
Azure AD B2C is used when you have a web/mobile application, and you want to allow clients to sign-in using different social identity providers (e.g. Facebook, Google) - in general, for an internal application (web or mobile).
In contrast, Azure AD B2B is used when an organization wants to allow users from another partner organization to access their resources. In this case, they need a mechanism for partner users to authenticate using their partner user identity.
Can I use Azure AD identities inside Azure B2C?
Yes, you can do it but would require to create an Azure AD Application that will be used by Azure B2C as to fetch user information using the custom IDP (Identity Providers).
In this way, the Azure AD users need to remember and manage only one password. The hook between the two requires a little customer configuration. A wonderful post from Rory Braybrook covers all necessary steps that need to be done. You will rely on OpenID Connect Provider to connect the AD to B2C.
Can I offer access to O365 resources using Azure AD B2C?
No, it is not possible. As I mentioned above, the B2C user information is stored in a separate user pool, without direct access to Microsoft services (e.g. Sharepoint). There is no capability to define custom policies for it. The only option available is Azure AD B2B.
Even so, there is support from Azure AD B2C for Microsoft Dynamics CRM.
Conclusion
In the below diagram, we can see a comparison between B2B and B2C. As we can see, using B2B we can provide access to resources and we rely on the federation. This requires us to create a 'stub' for each federated user inside our Azure AD. Additional to it, we can use Microsoft Identity for situations when our customer cannot do federation (with drawbacks related to user management).
Inside B2C we provide access to an application, but without the ability to share company resources. For each social network user identity, we store a small part of the information in B2C, even if the log-in is happening through external identity provider. As owner of B2C, we are responsible to manage the users life-cycle.
A simple way to make the difference between B2B and B2C is to have in mind what you want to share.
Let’s try to identify what are the main differences between and what are the limitations of the two options that we have available inside Azure AD.
Azure AD B2C
Azure AD B2C (Business2Customers) is for solutions that have a front-end and interaction with users. It enables us to have an identity system that supports users to sign-in using their own identity or identity created inside Azure B2C. Users can use their personal Facebook, Google, LinkedIn or Amazon account to log-in inside your application.
Azure AD B2B
Azure AD B2B (Business2Business) has a different purpose in comparison with B2C. The primary purpose of it is when customers want to share resources (e.g. files, Azure resources, Office 365 content) with external users. B2B involves federation between the customer AD tenant and customers tenants. It requires that the customer tenant be available from the internet.
We should note that even if users receive an invitation on their email account, at the moment when they accept the request, a new identity is created inside Azure AD. In comparison with Azure AD B2C, when the identity is persisted inside the identity provider (e.g. Facebook) and only specific information is shared with the Azure AD.
Features
(1) User Management
Inside B2B, the users are managed inside Azure AD, but they are marked differently. This enables the AD administrator to provide external users access to resources (e.g. files). In comparison, B2C users are managed separately, and they cannot receive rights to access resources.
(2) Single Sign-On (SSO)
B2B has full support for SSO, including Office365 and any other application integrated with Azure AD (including on-premises ones like Workday).
In contrast, the SSO support for B2C is limited, and the application owner owns it. There is no support to use SSO when you B2C users try to access Office365 or other Microsofts services. This happens because the B2C users are not managed in the same ‘pool’ as the AD users.
(3) Supported identities
Azure AD B2B has support for work and school accounts, together with federated accounts. All identities are stored in the same locations and can be managed from one central location.
In contrast, B2C supports only consumer users with local application accounts or with social identities that are federated with B2C. Even for a local account inside B2C, the accounts are not stored inside the AD pool. This is why sharing Microsoft resources (e.g. Sharepoint resources) is not possible in the B2C context.
(4) User lifecycle
The owner fully manages the lifecycle of identities inside B2B. For federated accounts, the user management is done by the partner identity provider; the B2B owner can specify only what resources can be accessed (e.g. user password management is not done in the Azure AD B2B pool, is done inside the identity provider pool).
In the B2C scenario, user management is done entirely by the customer, that has full control over it (related to user activity inside his application).
Azure AD B2B Insights
If you use Premium tier, for each user inside AD, you can connect up to 5 users from a federated identity provider.
Keep in mind that Microsoft accounts are also supported inside B2B. For non-AD or Microsoft accounts, the users receive an invitation on their personal account that will invite them to create a Microsoft account for it. In essence, the user needs to manage the account separately (including a separate password). The new Microsoft account that it is created in this case will be used when they sign-in, even if they use their personal email account (user@gmail.com).
Azure AD B2C Insights
When you use Azure AD B2C, there is a nice feature that allows us to collect additional user information after a specific time or after a specific number of log-ins. For example, after five log-ins, the user might be asked what car manufacturers he prefers. In this way, you can improve the user profile without requesting all this information during the registration phase. As for Azure AD B2B, the Azure AD B2C does not require your application to run inside Azure. Your application can be hosted on-premises or on another cloud provider, like AWS.
When to use it?
Azure AD B2C is used when you have a web/mobile application, and you want to allow clients to sign-in using different social identity providers (e.g. Facebook, Google) - in general, for an internal application (web or mobile).
In contrast, Azure AD B2B is used when an organization wants to allow users from another partner organization to access their resources. In this case, they need a mechanism for partner users to authenticate using their partner user identity.
Can I use Azure AD identities inside Azure B2C?
Yes, you can do it but would require to create an Azure AD Application that will be used by Azure B2C as to fetch user information using the custom IDP (Identity Providers).
In this way, the Azure AD users need to remember and manage only one password. The hook between the two requires a little customer configuration. A wonderful post from Rory Braybrook covers all necessary steps that need to be done. You will rely on OpenID Connect Provider to connect the AD to B2C.
Can I offer access to O365 resources using Azure AD B2C?
No, it is not possible. As I mentioned above, the B2C user information is stored in a separate user pool, without direct access to Microsoft services (e.g. Sharepoint). There is no capability to define custom policies for it. The only option available is Azure AD B2B.
Even so, there is support from Azure AD B2C for Microsoft Dynamics CRM.
In the below diagram, we can see a comparison between B2B and B2C. As we can see, using B2B we can provide access to resources and we rely on the federation. This requires us to create a 'stub' for each federated user inside our Azure AD. Additional to it, we can use Microsoft Identity for situations when our customer cannot do federation (with drawbacks related to user management).
Inside B2C we provide access to an application, but without the ability to share company resources. For each social network user identity, we store a small part of the information in B2C, even if the log-in is happening through external identity provider. As owner of B2C, we are responsible to manage the users life-cycle.
A simple way to make the difference between B2B and B2C is to have in mind what you want to share.
- Do you want to share access to a customer application? - B2C
- Do you want to share access to company resources? - B2B
Comments
Post a Comment