Here you can find the transcript of Episode #127 of PiaSys TechBites.
Welcome back to PiaSys Tech Bites. This week, I want to talk with you about Azure Active Directory Business to Consumer, which is a really powerful service provided by Microsoft, in order to create solutions that authenticate external users in a business to consumer scenario. With Azure AD B2C, you can easily authenticate users stored in your local directory, as well as users stored in external systems through external identity providers.
It supports various user flows, meaning flows to sign up, sign in, edit the profile of the users, do the password reset and stuff like that. It allows you to provide custom company branding for the login pages, and allows you to register applications like as you can do with the regular Azure Active Directory in Microsoft Azure.
You can use Microsoft Authentication Library, MSAL, in your code-based solutions to authenticate users. And you can use a set of REST APIs to access the content of the directory system of Azure AD B2C, to query and search for users and users’ properties.
Just to give you an idea, this is the list of external identity providers supported nowadays, at the time of this recording, by Azure AD B2C. And as you can see, there are plenty of options available. So, let me move to the demo environment, and let me show you how to use MSAL to authenticate users using Azure AD B2C, through an external identity provider.
So, here we are, in an Azure Active Directory Business to Consumer tenant that I created. And in order to do that, you simply need to go to the Azure Management Portal, and you need to create a new instance or a new tenant of Azure AD B2C. Now, in this tenant, I configured under identity providers, some identity providers, and specifically, I want to support local accounts in my current tenant, as well as GitHub accounts, which is under preview right now. Moreover, in the user flows, I configured a couple of user flows. I will focus my attention on the sign-up and sign-in one.
In order to create a flow, you simply need to click on new user flow. You need to choose the flavor or flow that you want to configure, for example, signing in and signing up as like as I did before, you can choose what kind of version you want. You should follow the recommendation. And when you create it, you will have to provide the name and choose the identity provider that you want to connect to this user flow.
Once you have done that, you are ready to go. And that’s why here I already have my signing up and signing in which is configured to support GitHub as the identity provider, the external identity provider, together with the local account, so with the mail sign up.
Moreover, in the app registrations, I registered an application in the Azure AD B2C tenant. This is my application, which has its own client ID like as any other application, regardless it is in B2C or not. I have, under the authentication section, configured my application to support mobile and desktop applications. And I’m going to use the HTTP localhost return URL, because I’m going to show you how to use this Azure AD B2C tenant to authenticate users in a console application, just for the sake of making an example.
And that’s why I configured my app to support public client flows, setting to yes, this flag. And as you can see here, I support accounts from any identity provider or the organizational directory, so that I can authenticate users with local accounts of my local Azure AD B2C tenant or with external identity providers, which means right now, GitHub which is the only one I configured for my tenant. If you want to have a look at the API permissions, we can see that we just have access to Microsoft Graph in order to authenticate the users. So, to get the OpenID of the users when we authenticate them.
So, let’s move to the consumer application. And here I have a console application where I added a reference to the NuGet package of MSAL. So, if we go under install, we see that we have microsoft.identity.client. And here, I simply configured the client ID of my application, which, of course, could be a setting in the application settings. But right now, for the sake of simplicity, I’m using a static string variable.
I have the authority, which is the name of my Azure AD B2C tenant .b2clogin.com, followed by the whole tenant name and the policy of the user flow that I want to use, and followed by oauth2/v2.0/token. This is the authority that we use with MSAL in order to authenticate users.
Moreover, I don’t want to get any specific permission scopes, so I simply create an empty array of permission scope request. And I create, using the public client application builder of MSAL, a new instance of the IPublicClientApplication type. I use the B2C authority that we defined just before and I provide the URI that I configured in my application. And as such, with the fluent API of MSAL, I build the PublicClientApplication object.
Once I’ve done that, I can simply acquire a token interactively. And using the AcquiredTokenInteractive method, I provide my empty array of scopes. And I will see that I will get back as a result, the ID token of the authenticated user, if any.
So, let me start this application. Let me, first of all, prepare a browser window. And then, let me start the application right here. So, let me switch to the console application and let me start it. The application will start and in the browser, in the browsing session that I created before, I can authenticate.
Either using the email and password of the user of my Azure AD B2C tenant, or by using GitHub, which is the one, the identity provider that I’m going to use right here. So, let me click on GitHub. I am already authenticated in GitHub. So, I will go through the authentication process really smoothly. And now, here I am authenticated and I have an ID token.
If I go to see the content of the ID token, we can switch back to the browser, we can go to jwt.ms, And we can see that we have been authenticated and we have a token which will have an expire, which has an issue and all of the information about the user flow that we used to authenticate. So, really simple and straightforward, and now we know in our application that the current user has been authenticated. If we dig into the result object, we can see that we also have information about the account of the user, so that we have information about who the user is.
So, that said, it’s really simple to use Azure AD B2C through MSAL, to create applications, which will authenticate users using external identity providers. But bear in mind that in such kind of scenarios, you are not usually allowed to consume APIs, like for example, those of Microsoft Graph or of Microsoft 365. In fact, if you go back to the app registration and you try to add a permission, you will see that under Microsoft Graph, you can only do the authentication of users and nothing more than that. You don’t have access to all of the APIs and all of the permissions that we have in a regular Azure AD tenant, because this is a B2C context, and here we don’t have Microsoft 365 and all the Microsoft ecosystem.
Like always, thank you for watching this video. I hope you found it interesting, and I’m really looking forward to seeing you next week. And remember to subscribe to this channel. Thank you.