There are a number of articles (see here for a good example) comparing Azure B2B – a feature of Azure AD – and Azure B2C – a special type of Azure AD tenant. Both of these are designed to allow external identities – users who are not employees of the directory owner – to gain access through these directories to resources they control. While one uses B to signify it’s focus on business partnerships, while the other uses C for consumers, at the end of the day either can be used to accomplish roughly the same access. My intent here is to focus on what I see as the fundamental difference; one that is most likely to drive the appropriate choice of technology.
The main strength of Azure AD and its B2B feature is the power of its authorization control, particularly features like Conditional Access, Entitlement Management, Privileged Access Management and security groups. Of these, B2C provides only a very limited version of CA and has, but does not use security groups. Furthermore, some applications – Office 365 in particular – can only be accessed through Azure AD. Therefore, if the intent is to expose high-value applications, where access control is particularly critical, Azure AD with its B2B features is the preferred platform.
The main strength of Azure B2C is its customizability, particularly support for custom user journeys, which allow calls to external REST functions, give extensive support for UX customization and, out-of-the box support a greater variety of social providers, other OpenID Connect IdPs as well as SAML and WS-Federation providers. These in turn support such unusual scenarios as LDAP authentication (via an API call), phone-only authentication, identity impersonation and user-created accounts. B2B on the other hand only allows users from other AADs, individually specified external WSFed and SAML (not OIDC) issuers and selected social providers (Google and Facebook).
Some applications, e.g. multi-tenant SaaS application could benefit from both sets of features: customizable way of supporting many different issuer types and strong tenant-owned authorization. While that may be the eventual intent of Microsoft (I am an employee of the company but not privy to any non-public product plans), today there are ways to accomplish some of that with additional custom code. Here is an example of such an application.