Building Application Identity Solutions using Azure AD B2C
Identity is a critical feature of most applications. When I build a new application, there are a common set of questions that I ask to start building out my product backlog:
- How does a new user sign up?
- How will I identify users?
- Will I manage my own users or use Facebook logins?
- Can business users log in using their Active Directory domain accounts?
- How do I implement Sign In with Apple for my iOS users?
- How do I store user information?
- How do I safely persist passwords?
- How do I implement multi-factor authentication?
Having an easy sign-up process is critical for gaining new users. Keeping their personal information secret is critical for maintaining user trust. Being able to identify and authorize user actions is critical for keeping the application and data secure.
In the earlier days, application developers used to have to implement login and user management on their own. With the growth of OAuth 2.0, OpenID Connect, and JSON Web Tokens, cloud services such as Auth0, Okta, Amazon Cognito, and Azure Active Directory B2C have risen up to provide these services for you and get your application running in hours and days versus weeks.
This is the first article in a series that will look at using Azure Active Directory B2C to build a customized identity management solution for cloud, web, mobile, and desktop applications. In this article, I will walk through the basic setup of an Azure AD B2C tenant and some of my recommendations for how to use Azure AD B2C for a product or series of products to help you to plan for using it for your own products and services.
What is Azure Active Directory B2C?
Azure Active Directory B2C is a service that manages user identities and authorizations for identified users to access services that your product provides. Azure Active Directory brings trusted Microsoft Active Directory features towards managing users for commercial products and not just enterprise domains. Azure Active Directory B2C is intended to be used to manage the user base for one or more applications, identify them using a set of approved identity providers, and generate secure access tokens that can be used to authorize user actions within your application or services. Azure Active Directory B2C implements OAuth 2 and OpenID Connect to provide both authentication and authorization services based on open standards.
Features of Azure Active Directory B2C include:
- Secure storage of user profile information
- Supports username/password authentication of users
- Supports authentication of users using third-party social media providers such as Facebook, Google, Apple, GitHub, and others
- Supports identification and authentication of users using Azure Active Directory domain accounts
- Single sign-on for most authentication providers
- Support for multi-factor authentication for users authenticated using passwords
- Fully customizable web-based user experiences for signing up, logging in, or performing user actions such as profile editing
Azure Active Directory B2C is a multi-tenant solution. You can create multiple Azure Active Directory B2C tenants in your Azure subscription. For example, if you wanted to keep users from different customers separate, you could create one B2C tenant for each customer.
How Much Does Azure Active Directory B2C Cost?
Before using any cloud-based service, it’s good to have an understanding of the cost model for the service. Fortunately, to get started with a new app, Azure Active Directory B2C is very reasonable and is not going to cost anything.
Pricing for Azure Active Directory B2C is based around the concept of Monthly Active Users. If you manage to collect 100,000 users, but only 50,000 of them sign into your application during the calendar month, you will only be charged for the 50,000 active users and not the total 100,000 users. And to go even further, Microsoft offers a free tier for B2C which covers your first 50,000 Monthly Active Users!
If you are lucky enough to get more than 50,000 users, you will be charged $0.00325/month for each additional user. If you get 100,000 active monthly users, the first 50,000 will continue to be free and your monthly cost for identity management will be $162.50. If you implement multi-factor authentication that requires either a telephone call or an SMS text, Microsoft will charge you $0.03 for each call or text. In a later article, I will cover the alternative to this that will allow you to perform multi-factor authentication using the user’s mobile device or a password manager and will allow you to skip the extra cost.
Do I Need Multiple Azure Active Directory B2C Tenants?
A common question when starting development on a new product or application is whether you need to create a new Azure Active Directory B2C tenant for each product? My recommendation depends on the situation.
For larger enterprise applications, some customers want to have their own instance or the appearance of having their own instance. Corporate customers might want their own isolated set of identities and not run into risks that their identities are mixing with their competitors. In that case, it’s obvious that you will need multiple tenants.
For consumer-based applications or non-enterprise Software-as-a-Service, it’s a different story. If your company has multiple applications, does it make sense to have one tenant for each application? My answer is no. You or your company are going to make a great effort and pay a cost to acquire every customer. Do you want to repeat that for every application? If you have a unique tenant for each application, you will need to convince your customers to sign up for the new application and you will pay the cost a second time.
For consumer-based applications and SaaS, my recommendation is to create a single B2C tenant that stores users for your complete application suite. This gives you several advantages:
- You acquire the customer once and convince them to sign up.
- Switching between applications is easy as users will have a single sign-on experience since all of your applications share the same Azure Active Directory B2C tenant.
- Only one directory to manage for all of your users.
- One cost to manage all of your users. 100,000 users in a single-tenant will cost you $162.50. If you have the same users in two tenants, you’re paying $325/month to manage the same identities.
That advice covers your production application. For development and experimental purposes, you should probably have at least two tenants: one for development and QA and another for your production environment. Or have one tenant for each of your own environments.
About the Demo Project
The Azure Active Directory B2C tenant that I will be creating for this blog post will be used for a project that I will be developing and documenting in many ways. So the stories and features that I will be implementing will be used in an actual application. As you follow along with these and other blog posts, you will have the opportunity to see and try most of these features live. I will do my best to describe or find other ways to show you the live implementations of features that I cannot share with you directly (videos or extra pictures).
Create an Azure Active Directory B2C Tenant
Let’s start by creating our Azure Active Directory B2C tenant.
The picture above shows my Azure Portal after I log in. I can create an Azure Active Directory B2C resource by clicking on the Create a Resource button and then searching for Azure Active Directory B2C in the search box. Selecting Azure Active Directory B2C from the list of available services. The Azure Portal will then show me the Azure Active Directory B2C product page.
Clicking on the Create button will then give you the option to create a new tenant or link to an existing tenant. We’ll choose to create a new tenant. We will be taken to the Create a tenant screen to enter the information about the new tenant:
There are three main fields on this form. The Organization Name field is used as the human-readable name of the directory. You should not use your organization’s name as you would with your company’s real Active Directory tenant. When creating a B2C tenant for a product, you should use the product’s name. For example, the demo project I am creating is called Project Center, so I will use Project Center for the organization name, or more specifically, Project Center (Development) for my tenant that I’m going to use for development use.
The initial domain name field is a unique domain prefix to use for the Azure Active Directory B2C tenant. This domain name will always be active, even if you later define a custom domain. The domain exists as a subdomain of the onmicrosoft.com domain. The initial domain name can only use alphanumeric characters, so punctuation such as hyphens or periods are not allowed. For my development tenant, I’m going to use projectcenterdev.
For the Country/region field, I’m going to use the United States, since that’s where I am located. This field is used to pick the data center where the directory is located, but the directory and B2C tenant will be usable by anyone globally.
Choosing a Resource Group
For the Resource group field, the value of this field takes some consideration. If you are not familiar with Azure, a resource group is a collection of related resources or Azure services that are managed together. In future posts, I will probably add other Azure services to my app in development and they will most likely be added to the same resource group. However, for your Azure Active Directory B2C tenant, I recommend putting your tenant in a separate resource group from the rest of your Azure resources.
Why do I make this recommendation? As I mentioned earlier, you may share the same B2C tenant among multiple applications. In that case, keeping your B2C tenant separate from any specific application kind of makes logical sense. Another reason for keeping your B2C tenant in its own resource group is that it makes it easier to develop and iterate on your product during development. Sometimes during development, you might feel the need to just wipe your Azure resources and recreate them. Maybe you made a bad decision and want to backtrack. Maybe you want to start working on a new feature with a clean slate. Maybe you want to create a temporary environment to tinker with, but still, use the identities in your development B2C tenant. By assigning your B2C tenant to its own resource group, you can painlessly wipe, rebuild, or create additional environments and you don’t risk the loss of the accumulated identity data or need to worry about rebuilding it for new environments. You can wipe your development or test environment by deleting the resource group, which deletes all of the resources in the resource group, but you do not have to worry about deleting your B2C tenant (which is a very involved, manual process that I’ll point you to later).
So the moral of the story is to keep your B2C tenants in separate resource groups from your application’s resources. You can create one resource group per B2C tenant, one resource group for B2C tenants for different application environments (development, test, and production) in the same resource group, or create one resource group for all of your B2C tenants. I don’t have a good argument for or against any of those approaches.
Placing Your Tenant
Another use of resource groups is to help you locate resources within the same Azure data center. However, resources can exist anywhere, even in different data centers than where the resource group is managed. For Azure Active Directory B2C, the resource group location isn’t significantly important. I typically choose the same data center where I’m planning on putting the other application resources. For other Azure resources, the data center is important because not all data centers support all available Azure resources. For help choosing a location, check out the Azure Geographies page to see what services are available in each data center.
I like staying close to home, so I’m going to choose the West US 3 data center which is down the street from me in El Mirage, AZ (I live in Surprise).
Taking a Quick Tour of Your New Tenant
After your B2C tenant gets created, refresh your browser and you should be able to switch to it. While your B2C tenant is a part of your subscription, it shows up as a separate Azure Active Directory instance that you need to switch to. If you click on your avatar in the upper right corner of the portal, you will see an option for Switch directory. Click that and you will see a list of directories that you can access, which should include your B2C tenant. Choose the B2C tenant and switch to it.
In the search bar on the Azure portal, search for Azure AD B2C. This will take you to the dashboard for your new B2C tenant:
In future posts, we’ll take a deep dive into the B2C settings. But feel free to take a look around and see some of the things that you can manage or customize for your B2C tenant.
Delete an Azure Active Directory B2C Tenant
I’m not quite ready to delete my B2C tenant at the moment, so I will not be providing you with a guided tour of that process. There are several steps that you are going to need to go through to get there. Microsoft provides a tutorial to guide you through the process. If you need to delete a tenant that you created, click here to learn how to delete your B2C tenant.
Where Did We Go?
In this post, I gave you a quick introduction to Azure Active Directory B2C, what it does, and why and how you should use it. I showed you how to create a B2C tenant and gave you a quick walkthrough of how to find the tenant’s console. In the end, I pointed you towards the instructions on how to delete a B2C tenant if you need to. We end this post with an active B2C tenant, but we can’t sign up for or log into an application yet using the B2C tenant. We’ll do that in the next post.
For more information about Azure Active Directory B2C, please see the documentation.
