B2B vs B2C Authentication in Azure

I’ve recently been involved in several projects around Microsoft Azure B2B and B2C, so I’ve set out some of my thoughts around the two systems, what purpose they serve, what the differences are and why you might want to choose one over the other.

What are they for?

One point of confusion is that despite the apparent similarity in their names, they serve different purposes.

• Azure B2B does not store any user credentials, and does not authenticate users. What it does do is to allow users who have already been authenticated by a third party to gain access to resources in your main Azure tenant.
• Azure B2C stores user credentials and provides mechanisms to authenticate an external user against these credentials and generate an access token. Azure B2C does not give external users access to your primary Azure tenant.

To make this clearer, consider the scenario below.

Azure AD

Imagine that you have a factory with a security fence around it and a gate that allows your staff in. Every morning you staff line up at the gate. The gatekeeper takes the name and password given by each member of staff, types it into their computer, and if they match, gives them a security pass that is valid for the day.

This is how user name and password authentication works on Azure. The staff member with the pass can use this to get into the factory, open doors, and operate machinery for as long as the pass is valid. Additionally the pass will be set up so that it will only allow each user to open certain permitted doors or operate specific machines.

How does MFA (Multi Factor Authentication) work in this case?
When MFA is in operation, the gatekeeper inputs the user name and password to his computer, which then sends a message to the user’s phone, which they then have to give to the gatekeeper before he will give them a pass.

So how would Azure B2B function in this scenario?

Azure B2B

Lets imagine now that you work with a supplier who has a compatible security system. From time to time their staff need to come and work in your factory. You could give them access using the same system you use for your staff, but that has a number of disadvantages:-

• They have an extra password and user name to remember.
• If they leave your supplier, you might not know about this, and they could come to your factory and gain access using the credentials you gave them.

Instead of this you make sure that your supplier’s staff go to their factory first and sign in and get an access pass for that factory. They then have to come to your gatehouse where your gatekeeper inspects their pass, and then issues them with a separate pass for your factory. The end result is that the external staff don’t have to remember an additional password.
In the event that they do leave your supplier, they will no longer be able to get the initial pass to use at your gatehouse.

Azure B2C

Now let’s suppose that your factory has a visitor centre, and that you want to give your customers access to this. However, you want to make sure that you can control who is coming in an out of any sensitive areas of the centre. Some parts might be open to anyone, but a lot of it is sensitive and if anyone wants to go into the sensitive areas will need to be properly identified and authorized.

You don’t want to use the main factory access system — that’s not what it was designed for, it creates extra management overhead and you don’t want to take any chance that customers might gain access into your factory by misusing the pass.

Instead of this you create a copy of the factory access system, and use this to control access to the customer visitor centre. This is set up so that your own staff or staff from suppliers can get access using their own pass, but other customers will have to use a separate username and password with MFA.
It can also be set up so that customers can sign themselves up to the system, rather than having to go through an enrollment process.

B2B issues

When working with B2B authentication there are a number of issues that regularly come up:

One of the most frequent is: what happens if your supplier has an incompatible authentication system?
Azure is actually divided up into several separate “clouds”: Azure Global, Azure China, Azure US gov and Azure Germany. If your supplier is based in a different cloud, you will be unable to interoperate with your supplier’s security system (or at least not without a lot of trouble and effort, or not at all, depending on the two organisations’ security postures).

One way round this can be to ask the supplier to setup a consumer account in the global cloud, which they can then use to access your security system in an SSO fashion. However, many organisations have policies that explicitly forbid staff from setting up separate accounts for this purpose. In any event doing this negates the benefits of having SSO access and introduces a number of security issues.

I’ve have encountered this issue, when having set up the infrastructure to make some documentation available to third parties through B2B: the issue came up that certain US defence suppliers use the US Gov cloud (which is unable to automatically authenticate with the global cloud through B2B). Getting the relevant system administration functions to enable mutual interoperation was not possible for security reasons. The end result was that the system architecture actively prevented a small but important percentage of the potential customers from accessing the documentation.

A second common issue is with the “email address” that you use to invite a user to join B2B. Every user has to be invited individually, and in 99% of cases it is fine just to use their email address. The problems tend to arise with organisations on the very large or very small end of the size range. In all cases, it is important to realise that you need to be inviting a user using their UPN, and not an email alias. In the vast majority of cases these are the same — their email address will be john.smith@someairline.com, and using this for an invitation to B2B will work just fine.

However, there are companies that ask users to log in using a user name that is not their email address, so John Smith (above) could belogging in as u123456@someairline.com, but he has an email alias of john.smith@someairline.com, so naturally that’s what he asks to be invited as. He will receive the invitation, but when he tries to log in, it doesn’t work. So there will inevitably be a lengthy period of investigation to eventually discover that his UPN is not the same as his email address. (Although, once the problem is understood, sending the invite to their UPN will resolve the problem)

At the other end of the spectrum are very small organisations with somewhat “casually” managed Azure tenants. They may only have a MS office subscription, and the organisation may have changed names and email addresses several times, the level of technical knowledge in their system administration may be quite low, so getting to the bottom of what their UPN actually is can be quite challenging.
A further issue is when users change name (for example, on mariage) a user’s email address may change, but they still have a UPN with the original name.

In most cases, B2B will allow you to get SSO up and running with partner organisations without too much difficulty, but you do need to be aware of the edge cases that will likely consume most of your support time.
It does deliver the benefits of SSO in most cases and prevents leavers from continuing to have access to your systems.

B2C Issues

If you implement a solution using B2C you can avoid the issues above, as you are moving the “authentication boundary” back under your control, however you then need to be careful to avoid the trap of developing a highly complex solution with its own maintenance and support issues.

B2C will allow you to authenticate users based on their email address and password (with the option to require MFA) This is entirely independent of the user’s own organisation. So long as they have a working email address, they should be able to sign up with b2c and access resources that you give them permission for.

There are downsides here: -

• You are asking them to remember an additional password, negating any benefits of SSO.
• You have no connection with the partner organisation that tells you if the user is still working there — leavers could continue to access your resources even after they have left the other organisation.

Fortunately B2C will, with some effort, will allow you to set it up to use external systems such as Microsoft Azure or Gmail as an authentication provider, so you can get very close to the seamless B2B SSO experience using one of the providers listed below. Unlike B2B, B2C has the added benefit that where incompatibilites make SSO impossible, it is still possible to fall back on a username/password login using the customer’s email address.

Setting up B2C can be a very straightforward experience, it is well documented and as long as you make use of out of the box “User Flows” and have straightforward requirements that can be managed out of the box then you should have no problems.

Where complexity can start to cause issues is where the requirements go beyond out of the box, and you start to need to implement custom flows to meet these requirements. This could be because you want to send a custom sign-up link to the user, or where you want to ask for additional information during sign-up or login.

Writing custom flows requires the creation of very verbose XML files, and while you can define every detail of every step, this is not something to take lightly. Implementing a custom flow is likely to take at many times longer than a user flow, and even longer if you need to lean about custom flows and how to write them.

A further point to be aware of is that B2C operates in its own separate Azure tenant, it will not give users access to your main Azure tenant. In many cases this is actually an advantage from a security point of view, as there is no possibility of external users being given access to Azure resources in your main tenant.

Summary

B2B is a good solution if you need to interact with a well defined group of organisations where you can be sure that there will be no problems inviting users from the partner organisation (At the very least you will need to ensure that any potential issues, such as with UPNs or separate Azure clouds are well understood and have known work arounds).

Where B2B does not work so well is where you are trying to invite users from a disparate group of organisations who are not known and tested in advance. B2B is not a generic authentication solution that can be used to easily get any user from any organisation to SSO with your own organisation.

B2C is a better solution if you do not know in advance the identity or origin of your user base. Ideally you will set it up with an out of the box user flow. It can be used to enable SSO with partner organisations while still retaining the option of a user name+password based login.

Where B2C becomes problematic is when you have highly complex authentication requirements requiring the creation of custom flows. These require a high level of knowledge and expertise to develop and a significant amount of time. I would strongly recommend keeping control of project scope in these cases with a view to avoiding the use of custom flows.