One of my projects is currently using Azure AD for authentication. It does its job of providing access to registered users and keeping bad actors out of the system. However, it poses a small limitation that is pretty significant.
Azure AD is like a federated user account system of some sort. You can create an account within it. But it only lives within your Azure directory. No matter what account you create, regardless of permissions or anything, it will always be a <directory name>.onmicrosoft.com account (e.g. testuser@azuredirectory.onmicrosoft.com). It’s not really that big of a problem until you try to accommodate people outside your Azure ecosystem.
There are certain times when you want to accommodate more users but these users are not willing to jump the hoops to create an account within your directory. Some users are already a part of a different federated account system. Some users just use a generic account from Google, Amazon, or Microsoft, and then there are certain users that probably just want to use their social media accounts to log in to everything (not something I would suggest, but different strokes for different folks).
In case you’re in the same situation as us, then you probably should consider moving to Azure AD B2C.
At this point, I’m still trying to understand the entire Azure ecosystem and I still have a lot to learn. So I went on my way to look for articles on how it works and how it can be implemented. There are lots of materials online discussing how it works. However, most, if not all, of those materials are written in .NET Core. The project I’m working on is still using .NET 4.8. I know it’s highly possible that the B2C implementation is exclusively for .NET Core and up since I can’t find any articles about it in the context of .NET 4.8. But I know I’m not the only one who thought of doing this and someone probably did something about it already. So I kept on digging.
Lo and behold, there IS in fact a sample code in .NET 4.8 that has a B2C implementation in it. You can find it here: Azure AD B2C: Call an ASP.NET Web API from an ASP.NET Web App
I first thought this migration from Azure AD to Azure AD B2C will be really hard to do since I’m using an old version of the framework for a new feature. But it’s not really as hard as I thought it was.
On first look, the conventions used in Azure AD and Azure AD B2C are not really that far from each other, if at all. They use the same library Microsoft.Owin.Security.OpenIdConnect and the interface IAppBuilder, which means the classes, methods, and interfaces are the same, which means modifications should be at a minimum.
Now, just because the library is the same and the interface is the same, that does not mean the declarations are the same as well.
There are specific parts where it is the same, like ClientID, RedirectUri, and PostLogoutRedirectUri. But there are certain fields that were new to our implementation, like MetadataAddress. It appears to be the address that provides the OpenID configuration for the given Tenant and User Flow Policy combination.
The metadata address should look something like this: https://<directory>.b2clogin.com/tfp/<tenant>/<userFlowPolicy>/v2.0/.well-known/openid-configuration
The Tenant is the domain name of your B2C instance.
The User Flow Policy is the one you would define in the User Flows section of the B2C configuration in Azure Portal.
User Flows are basically pre-defined types of process flows that developers can use to make account management simple and secure for users. It is like making your own account management pages except you make Azure AD B2C do it for you. Example user flows include sign-up and sign-in (SUSI), profile editing, and password reset.
There are a lot of things to be discussed here. But this article is only intended to present the fact that you don’t need the latest version of .NET to implement your own B2C authentication. A lot of videos have been created on the subject already, albeit in .NET Core. But they do a good job in explaining how to do this, from setting up your own directory to creating your own user flow. One video I would recommend is the one from WintellectNOW.
As for the web.config, here’s a quick reference:
- Tenant – the B2C domain name.
- TenantID – the Directory ID. You can find this in App Registrations or when you’re trying to switch directories in the Azure Portal.
- ClientID – the Application ID. This can also be found in App Registrations
- ClientSecret – this is a computer-generated code that would help in keeping your B2C implementation secure. Within an app registration, you will see Certificates and Secrets in the Manage section. That’s where you can create a secret key.
- AadInstance – this is a URL of the B2C login instance with the correct Tenant and User Flow Policy. It should look something like this: https://<directory>.b2clogin.com/tfp/<tenant>/<userFlowPolicy>
- RedirectUri – the URL to the redirect page for authenticated users
- SignUpSignInPolicyId, EditProfilePolicyId, and ResetPasswordPolicyId – these are User Flow Policies for sign-up/sign-in, edit profile, and reset password, respectively
- ApiIdentifier – this is necessary for defining the scope of the requests.
Bien is a software engineer for more than 10 years, focusing on Microsoft .NET technology. He developed solutions ranging from embedded systems to accounting systems. He spends his free time trying to understand the world and its people.