Azure AD B2C is Microsoft’s preferred identity provider for Power Apps Portals. In this post, I’ll provide an overview of the technology, why it’s Microsoft’s preferred identity provider, and a few tips on how to set it up.

What is Azure AD B2C?

If you’re not familiar with it, I strongly encourage you to read up on Azure AD B2C. The B2C stands for “business to consumer”, and it allows you to offer a variety of sign in options through this single technology.

At a high level, Azure AD B2C is an identity provider, which itself supports using other identity providers. So, to an application like Power Apps Portals, it sees only a single identity provider. When you click the login button, you are taken to an Azure AD B2C sign in page, which then provides sign in buttons for the various identity providers you’ve configured in Azure AD B2C.

Supported identity providers as of the writing of this blog include Amazon, Facebook, Google, LinkedIn, Microsoft Account, and Twitter, with GitHub, QQ, WeChat and Weibo also available in preview. In addition to those, Azure AD B2C also supports any OpenID Connect compliant provider, making it possible to integrate with a variety of different providers, including Azure AD and custom schemes.

Azure AD B2C also supports what’s called local accounts which means users can create customer username and passwords specific to your applications. Again, since Azure AD B2C is managing all of this for you, your applications don’t have to care what type of account is being used to login, and doesn’t have to worry about passwords, resets, forgotten usernames, etc.

You are also able to customize/brand the Azure AD B2C login pages, so that it feels like just another page on your Portal.

Another great feature is that it support claims, which means that the identity providers can provide information about the users (think data like name and email address) automatically (with permission from the user, of course), which can be passed to the Portal and can be used to populate fields on the contact record.

Why Should You Use It?

If you read my previous post, you might be asking yourself why this is necessary, since Power Apps Portals already supports having many different identity providers. Why would you bother signing up for another service?

First of all, because Microsoft recommends it.

Obviously I can’t speak on Microsoft’s behalf, but I can guess as to why I believe Azure AD B2C is their preferred choice: there is a team at Microsoft whose job is to deal with consumer-facing login, and that is the Azure AD B2C team, not the Portal team. Rather than have two different teams working on this, wouldn’t it be better (at least for Microsoft) to just have one?

From a more selfish perspective, what team do you think is going to be responsive to changes to how authentication works in the industry? No offense to the Portals team, but they have a lot on their plate, whereas that is the sole focus of the Azure AD B2C team. Using Azure AD B2C means you’ll most likely be able to leverage new technology for authentication quicker than if you’re using the authentication technologies provided directly by the Portal.

If you’re an existing Portal customer, unfortunately at this point, that may be easier said than done. Power Apps Portals actually supports more authentication types than Azure AD B2C (things like SAML 2.0 and WS-Federation). These are older technologies, but there is no easy switch to Azure AD B2C if you need to keep using them. However, if you are willing to transition to Azure AD B2C, Microsoft has made that process easy (see the link above).

I personally hope that Power Apps Portals never moves to use Azure AD B2C exclusively, however I wouldn’t be surprised if they moved to support only a single protocol like Open ID Connect.

How Do You Set Up Azure AD B2C With Power Apps Portals?

The Microsoft documentation on how to add Azure AD B2C can be found here.

Long story short, Power Apps Portals doesn’t have any code specific to Azure AD B2C. Since Azure AD B2C implements Open ID Connect, you can add it to your Portals like any other Open ID Connect provider.

The documentation from Microsoft works well for configuring the Portal side, however I’ve found that the documentation on actually setting up Azure AD B2C to be a bit dated. To be fair to the Portals team, the interfaces to configure things in Azure are changing so often that it’s probably hard to keep up with everything. So here are a few pointers when trying to follow the documentation:

• To create a “Sign up and sign in” policy, use the User flows (policies) area. Here you can configure things like which identity providers to use, if you want custom sign up pages, and which claims you want to include.

  

• To find the Issuer (iss) claim field, look in the Properties of the “Sign up and sign in policy”.

  

• In the new interface, I don’t see anywhere that gives you the value you need for Policy-Signin-URL (the documentation says to look for Metadata endpoint for this policy, which I can’t find). This value goes into the Authentication/OpenIdConnect/[Federation-Name]/Authority Site Setting, and should look something like https://login.microsoftonline.com/tfp/yourb2cdomain.onmicrosoft.com/B2C_1_SuSi/v2.0, where you replace yourb2cdomain based on your Azure AD B2C tenant, and you replace B2C_1_SuSi with the name of your “Sign up and sign in” User Flow.

Once you’ve got the basics setup, you can take it to another level by customizing the Azure AD B2C login pages – the documentation covers that as well. This allows you to brand your page in such a way that the login page feels like it is just another page on your Portal.

In my next post, I’m going to take it a step further and customize the registration experience as well, which allows you to capture custom fields during the Portal registration process, something not possible with the out-of-the-box Portals local authentication.