B2C vs B2B vs B2B2E CIAM

Heya,

What are the differences between customer identity and access management (CIAM) systems for business to consumer (B2C) applications when compared to business to business (B2B) or business to business to employee (B2B2E) applications.

This question came up on the IDPro Slack a few weeks ago and I thought I'd take a swing at characterizing these.

What Do These Acronyms Mean?

The initial B in these acronyms represents the business building the application as well as maintaining the user data store (the CIAM system).

B2C stands for business to consumer, which means the application is aimed at end consumers. For example, applications like Spotify or Snapchat are B2C.

B2B stands for business to business. In this case, the application is built to serve business customers. Examples of this type of application include Quickbooks and Mailchimp.

B2B2E is an acronym for business to business to employee. In this situation, the application is meant to serve other businesses, which will make it available to their employees. Examples of this include Salesforce and Amazon Web Services.

Each of these CIAM systems is shaped by both the application users' and the purchasers' needs.

B2C

Consumers don't typically have to use your application; they have other choices. Therefore, if you are building an application to engage them, you best make sure the registration and authentication processes are smooth.

These businesses also usually depend on a game of numbers: if N users sign up, 0.1 * N will actually use it and 0.01 * N will pay for it. (Actual coefficients vary.)

This means that a flexible self-service registration process is important. You want to make sure you can capture the information you need. The type of registration varies depending on the application, though. You also want to consider progressive registration, where the application allows a user to get in and experience the benefits of it as soon as possible, possibly even anonymously. You can then throw up gates asking for profile data and possibly payment information as the user understands the value of the system.

Because any person can register for these applications, providing a way for them to verify real world ownership of login identifiers is important. The way this is usually done at scale is email or phone number verification. While not perfect, that process proves ownership of the email or phone number at the time of verification.

Along with simple self-service registration, the scale of many B2C applications means you also want self-service profile management, including credentials, and self-service account recovery. Both of these will allow you to serve millions or hundreds of millions of users without scaling up your customer service department.

With B2C you may or may not provide the ability to log in via federation, but if you do, you'll want to support identity providers used by your user population. For example, if you are targeting folks in the USA, you probably want to include Google or Facebook, but if you are targeting Chinese consumers, those providers would not make sense. There may be federation candidates based on the interests of your users, such as GitHub for developers or Discord for gamers.

You will also want to provide other low-friction methods of authentication, such as magic links.

Finally, while some consumers may have a sophisticated understanding of online account security, many may balk at any form of MFA. To ease friction, you'll probably want to offer many forms of MFA, including some that are in general less secure. SMS may have problems, but allowing that as a second factor of authentication is relatively easy and better than nothing.

B2B

B2B applications are aimed at people who are trying to accomplish some business goal. Because of that, some buyers may have only one user, while others will have a team. You'll want to build in the concept of organizations, which includes the ability to add or remove team members.

With a B2B application, you're far more likely to collect payment, even if you offer a free trial.

Self-service registration, profile management and account recovery still are important pieces of functionality, but account verification becomes slightly less important because the payment process offers a better way to tie the online account to a real world identity.

Support for more rigorous multi-factor authentication methods is more important. Business employees are likely to be able to use solutions like time based one time passwords (TOTP) or passkeys. Business owners may insist their employees do so.

B2B2E

With B2B2E, the application target is still business users, but the customers have their own directories of employees. Instead of self-service registration being enabled, user access and profile information is pulled from these directories. This can be done proactively, via standards like SCIM, or just-in-time, using SAML or OIDC to provision accounts when the user has authenticated at the remote directory.

The CIAM system will also need to map attributes from the remote directory into the user authorization schema of the application. For example, groups and roles from the customer's system will have analogs in the application; this mapping will be a bit of integration work.

Because the identity is owned by the federated directory, self-service account recovery is not needed. Profile management needs are less than in other cases, but may still exist, because there may be application specific profile data.

One concern that is unique to this category is the ability to quickly revoke access. When an employee is removed from a company's directory, their access to the application that relies on that directory should be removed as well. This has impacts on the identity architecture and implementation, such as token lifetime.

Depending on the characteristics of the remote directory, the rigor of onboarding, and the security needs of the application, account verification may be required. If you allow any customer to add an identity provider, and a malicious customer sets up a directory that allows them to add arbitrary email addresses as 'valid' ones, you run the risk of account takeover of legitimate employee accounts.

Multi-factor authentication may be either delegated to the employee directory or included in the CIAM system. This decision depends on the risk profile of an account takeover.

A Spectrum Of Applications

There is overlap between these categories. For example, Instagram is primarily B2C, but can be used as a B2B application. It's pretty common for a company to build a B2B application and then offer the ability to manage users via an external directory (the B2B2E use case) to segment customers by enterprisey feature requirements and charge more for that.

But in general, figure out which of these broad categories you are in and use that to refine your requirements for your application and CIAM system.

Dan