The Microsoft identity platform is a comprehensive set of components that help developers to build applications that sign users in with various types of accounts, such as Microsoft identities or social media accounts. The types of applications that can make use of the platform and its components include web applications, web APIs, and mobile apps.

The Microsoft identity platform components consist of authentication services, a set of open source libraries, and various application management tools. These different sorts of tools are specified in more detail as follows:

• Industry standards: The base platform is completely based on industry standards, such as OAuth 2.0, OpenID Connect, and SAML v2.0.
• Identities: The platform offers developers the ability to use the OpenID Connect standard-compliant authentication service to authenticate using a variety of identity types:
  • Work or school accounts: These are stored in Azure Active Directory (Azure AD).
  • Personal Microsoft accounts: For example, Xbox, Outlook, Skype, and Hotmail accounts.
  • Social or local accounts: With Azure AD B2C, you can use both social accounts (such as Facebook, Google, and Twitter) or local (external database or partner email) accounts. Azure App Services authentication supports authenticating using Azure AD and a few social accounts, such as Facebook and Google.
• Open source libraries: The Microsoft identity platform offers the Microsoft Authentication Library (MSAL) and support for other standard-compliant libraries.
• Application management portal: Applications can be registered and configured in Azure AD by using the Azure portal. From here, applications can also be configured.
• Application configuration API and PowerShell: The Microsoft identity platform has support for registering and configuring your applications using the Graph API and PowerShell. Using this programmatic approach, these tasks can be automated using your CI/CD pipelines.

The following diagram illustrates the different components of what the Microsoft identity platform is made of:

Figure 1.1 – Microsoft identity platform overview

In the next section, we are going to investigate the evolution of the Microsoft identity platform.

The Microsoft identity platform is the evolution of the Azure AD developer platform. Many developers have worked with the Azure AD platform previously to authenticate against Azure AD. For this, they have used the Azure AD v1.0 endpoint to authenticate using only work or school accounts. Work and school accounts are accounts that are all provisioned in Azure AD.

By using the Azure portal, the Microsoft Graph API, and the Azure AD Authentication Library (ADAL), developers can request access tokens from the Azure AD v1.0 endpoint. This can be done for both single-tenant apps as well as for multi-tenant apps.

By using the unified Microsoft identity platform (v2.0), you can authenticate using multiple types of accounts. It supports both organizational and consumer accounts to authenticate users. Unlike the v1.0 endpoint, the v2.0 endpoint is capable of authenticating using work or school accounts (that are provisioned in Azure AD), personal accounts, (Outlook, Xbox, Skype, or Live accounts), and social media accounts (for Azure AD B2C). Now you only have to write code once and you can authenticate with any Microsoft identity in your application.

You can add the open source MSAL, which is supported for several platforms, such as .NET, JavaScript, Java, and Python. Microsoft highly recommends using MSAL to connect to the identity platform endpoints. MSAL is highly reliable and has great performance, is easy to use, has support for single sign-on (SSO), and is developed using the Microsoft Secure Development Lifecycle (SDL). SDL is a topic of its own and way beyond the scope of this book, but in short, it is a software development process proposed and used by Microsoft internally that helps to reduce maintenance costs and increases the reliability of software related to software security.

The v2.0 endpoint also provides support for dynamic and incremental consent. This means that instead of specifying all the permissions upfront when you register your app in Azure AD, you can request the permissions incrementally. You only request consent for a basic set of permissions upfront that an ordinary user can consent to themselves. For instance, the ability to read their own profile data. Then, when a user tries to access different data in the application, such as a list of groups in the user's organization, the application will ask for the user or administrator's consent, depending on the permissions and how the tenant is configured. This will be covered in more detail later in this chapter.

MSAL also supports Azure AD Business to Consumer (Azure AD B2C). Customers that are using your applications and APIs can also use their social accounts to log in to the application.

In the next diagram, you will see an overview of the Microsoft identity experience at a high level, compared to the Azure AD developer platform:

Figure 1.2 – Microsoft identity platform experience

Important Note

MSAL.NET can now directly connect to an ADFS authority. It does not need to go through Azure AD. This is only supported from AD FS 2019 and above. For more information, you can refer to https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/ADFS-support.

Now that we have some background information about the Microsoft identity platform and its predecessor, the Azure AD for Developers platform, we can now dive into Azure AD, which is the backbone for all applications and permissions in Azure.

Azure AD provides a cloud-based enterprise directory and identity management service. It offers features to give users seamless access to all types of resources, internal and external. For instance, it enables the traditional method of user authentication through a username and password, along with the management of roles and permissions to give users access to a variety of resources and products, such as the Azure portal, applications inside of the corporate network, and also Software as a Service (SaaS) applications and Office 365.

It offers traditional username and password management as well as roles and permissions management. On top of that, it offers more enterprise-grade features, such as multi-factor authentication (MFA), and SSO for your applications. It also offers different monitoring and alerting capabilities out of the box.

Azure AD offers different pricing plans, all coming with different types of features and capabilities:

• Free: You can gain access to the most basic features by choosing this plan. This consists of support for approximately 500,000 identity objects, seamless SSO, device registration, Azure AD Join, user and group management, external identities with Azure AD B2B, Pass-Through Authentication (PTA), self-service password change, groups, and standard security reports.
• Office 365 apps: This offers no object limit, has an Service-level Agreement (SLA) for 99.9% uptime, self-service password reset for cloud users, company branding features, and device write-back (a two-way sync for device objects between on-premises directories and Azure).
• Premium P1: This offers advanced reporting, MFA and Conditional Access, Advanced Group Access Management, support for the application proxy, which can be used to provides secure remote access to on-premises web applications, Azure Information Protection (AIP) integration, Microsoft Cloud App Discovery, Azure AD Join, MDM auto-enrollment, and local admin policy customization.
• Premium P2: This offers identity protection, Privileged Identity Management (PIM), access reviews, and entitlement management.

  Important Note

  For a detailed overview of all the different features for each pricing plan, you can refer to the following site: https://azure.microsoft.com/en-us/pricing/details/active-directory/.

Azure AD is also used to manage user identities in Microsoft 365. Microsoft 365 is a collection of different services, such as Windows 10, Office 365, and Enterprise Mobility. By default, your Microsoft 365 subscription comes with the free plan of Azure AD, but you can also purchase different plans to get more features.

For developers, Azure AD is primarily used for issuing tokens that enable users to sign in to applications. Before these tokens can be issued, applications need to be registered inside Azure AD, permissions need to be set, and users need to be added that can access the applications or have access to Microsoft 365 data. This is mainly done by IT administrators, but it is also important for developers to know how to put this in place. Developers can also make use of the enterprise-grade security features in Azure AD, such as Conditional Access policies and SSO, for example.

Next to the fact that an Azure AD tenant is created together with your sign-up for an Azure, Microsoft 365, Office 365, or Intune account, you can also create an Azure AD tenant manually. An Azure AD tenant is basically a representation of an organization. You create a dedicated instance of Azure AD bound to the organization. It is also possible to create multiple Azure AD tenants. Each Azure AD tenant is completely separated from other Azure AD tenants and has its own work or school identities, Azure AD B2C consumer identities, and app registrations. An app registration can be single-tenant, which only allows authentications from accounts within the tenant where it is registered, or multi-tenant, which allows authentications from all tenants.

In the next sections, we will briefly introduce Azure AD Business to Business (B2B) and Azure AD Business to Consumer (B2C).

This book is focusing on Azure AD from a developer's perspective. This means that, as a developer, you will not work with Azure AD B2B very often, although Microsoft Graph does offer APIs for Azure AD B2B that you can leverage inside your custom applications. You may encounter Azure AD B2B users in the solutions you build.

But, to give a complete overview of the different products and services that Azure AD has to offer, I will give a short introduction to this feature as well.

Azure AD B2B collaboration is a feature on top of Azure AD. You can add external identities to your Azure AD tenant to collaborate with external users inside your organization. Partners or individuals are not required to have an Azure AD or even an IT department. Azure AD B2B uses a simple redemption process to give access to your company resources, Azure environment, or Office 365 environment, using their own credentials. Partners use their own Azure identity management solution with Azure AD B2B. This reduces the administrative overhead that comes with managing accounts with external users. External users can log in to Azure AD-connected apps and services using their own work, school, personal, or social media identities.

Azure AD B2B APIs (using Microsoft Graph) can be used by developers to customize the invitation process or write applications such as self-service sign-up portals. Azure AD External Identities uses a billing model based on monthly active users (MAU), which is basically the same for Azure AD B2C. The first 50,000 users are free, then there is a monthly charge per monthly active user.

Azure AD B2B offers the following features:

• Management portal: Azure AD B2B is part of Azure AD, which means that all external users can be managed from the Azure portal. This is fully integrated with Azure AD, and the user experience is completely the same as for internal users.
• Groups: You can create groups for external users or add them to dynamic groups. With dynamic groups, administrators can set up rules to populate groups based on user attributes.
• Conditional Access: With Conditional Access, you can set conditions for your users. You can enforce external users to use MFA or give them access to certain applications or access from limited locations or devices.
• Auditing and reporting: Azure AD B2B is an add-on to Azure AD, which means you can use the auditing ad reporting capabilities that are part of Azure AD. For instance, you can look into the invitation history and acceptance details.

In the next section, we will introduce Azure AD B2C.

Azure AD B2C is a business-to-customer identity as a service aimed at public-facing mobile and web applications. Customers can use their preferred social, enterprise, or local account identities to get SSO access to your applications and APIs. These applications can be hosted everywhere, in Azure or other cloud providers, but also on-premises.

It offers a set of out-of-the-box authentication providers. These authentication providers can be used in your apps and custom APIs. For this, it uses industry-standard protocols and libraries, such as OAuth 2.0, OpenID Connect, and MSAL.

This means that developers don't have to add additional SDKs for making use of these authentication providers manually to their code; that is all handled by Microsoft and embedded in the SDKs that are used for authenticating against Azure. As well as the authentication providers that are offered by Azure AD B2C, you can also add your own authentication providers.

Azure AD B2C offers the following account types:

• Social accounts: Such as Facebook, Google, LinkedIn, and Twitter.
• Enterprise accounts: Azure AD accounts, or other accounts that use open standards protocols.
• Local accounts: These are accounts using email address/username and password and are registered inside the Azure AD B2C portal.

Your application needs to be registered inside the Azure B2C tenant. After registration, built-in flows and policies can be configured for the app inside the Azure AD B2C portal, where you can enable different authentication providers, set claims, and enable MFA that be used inside your applications. By configuring these user flows inside of the Azure AD B2C portal, they can easily be reused in different types of applications.

Important Note

Azure AD B2C is covered in more detail in Part 3 of this book: Azure AD Business to Consumer.

In the next section, we are going to set up the Azure AD tenant that we are going to use for all the demos in this book.

In this section, we are going to set up a new Azure AD tenant inside an Azure subscription.

Important Note

If you are new to Azure and don't have a subscription already, you can sign up for a free account here: https://azure.microsoft.com/en-us/free/.

Microsoft also offers the Microsoft 365 Developer Program. Here you can sign up for an E5 licensed tenant with no need to sign up for a subscription, no credit card needed, and you get access to sample data packs. The tenant is live by default for 90 days and it will automatically renew if it is actively used. If you want to use an environment that includes a fully functional E5 license including all the features and sample data, this is the way to go. You can sign up for this program here: https://developer.microsoft.com/en-us/microsoft-365/dev-program.

To create a new Azure AD tenant, you have to take the following steps:

1. Open a web browser and navigate to https://portal.azure.com.
2. In the overview page of Azure AD, in the top menu, select + Create a resource:

Figure 1.3 – Azure portal overview

3. Search for Azure Active Directory in the search box and select it.
4. Click the Create button to start creating a new Azure AD tenant.
5. Next, in the Basic tab, you need to select the type of tenant that you want to create, an Azure Active Directory or Azure Active Directory (B2C) tenant. Azure Active Directory will be selected by default. Make sure that it is selected and click Next: Configuration:

Figure 1.4 – Selecting the type of tenant to create

6. In the next screen, you need to specify the values for the Azure AD tenant. I've used the following values, but you have to fill in a unique name here:
   • Organization name: PacktPubDev.
   • Initial domain name: PacktPubDev. This will result in the following domain name: PacktPubDev.onmicrosoft.com.
   • Country/Region: Here, select your current country or region.

Your settings will look like the following screenshot:

Figure 1.5 – Specifying Azure AD tenant details

7. Click Review + create and Create. If needed, prove that you are not a robot and then click Submit to create the Azure AD tenant.

It will take a couple of minutes before the Azure AD tenant is created. After it is created, we can start adding our first user to it. Let's cover this in the next section.

Now that we have our Azure AD tenant in place, we can add our first user to it. For this, you have to take the following steps:

1. We first need to ensure that the new directory that was created in the previous step is active. For this, we need to select the directory icon in the top-right menu, and then select the Azure AD tenant that we have just created:

Figure 1.6 – Selecting the new Azure AD tenant

Tip

If the directory is not yet available in the list, you need to log out and log in again. Then, open the directory menu again and select the directory.

2. Now that we have selected the right directory, we can navigate to the Azure AD tenant.
3. On the Overview page of the Azure portal, type Azure Active Directory in the top search box and select it. The Azure AD Overview page will be displayed.
4. In the left menu, under Manage, select Users:

Figure 1.7 – Selecting Users in the menu

5. In the top menu, select + New user:

Figure 1.8 – Creating a new user

6. Specify the required values as follows:
   • Username: packdemouser1.
   • Name: Packt DemoUser1.
   • First name: Packt.
   • Last name: DemoUser1.
   • Password: You can choose between letting Azure auto-generate a password or creating your own password. In this case, leave the default value.

This will look like the following screenshot:

Figure 1.9 – Specifying the user values

7. Click Create.

We have now created a new user in our Azure AD tenant. In the next section, we are going to cover how you can delete the Azure AD tenant when it is not needed anymore.

If you don't intend to continue using the Azure AD tenant, you can easily delete it. If you are planning on using this tenant for the rest of the book, you can skip this part and come back to it when you are ready to delete the tenant.

To delete an Azure AD tenant in the Azure portal, you have to take the following steps:

1. On the Overview page of Azure AD, in the top menu, select Manage tenants:

Figure 1.10 – Managing tenants

2. Then, select the Azure AD tenant that you want to delete from the list, and click on Delete in the top menu:

Figure 1.11 – Deleting a tenant

3. Before you can delete the tenant, the users need to be deleted; therefore, under Required action, click Delete all users:

Figure 1.12 – Deleting tenant settings

4. You will be redirected to the Users tab where you can delete all the users. Select the users and then in the top menu, click Delete user:

Figure 1.13 – Deleting users

5. Click OK when you are asked if you want to delete the selected users.
6. You will notice that the Azure AD administrator cannot be deleted. Navigate back to the Azure AD Overview page and click on Delete tenant again. Now, you will see that there are no required actions, and you can delete the tenant by clicking the Delete button:

Figure 1.14 – Deleting an Azure AD tenant

We have now cleaned up our resources by deleting the Azure AD tenant. This concludes this chapter.

In this chapter, we introduced the Microsoft identity platform. We covered all the different features and capabilities that it has to offer from a high level. Next, we covered Azure AD and the different products that it has to offer. We looked at Azure AD B2B and Azure AD B2C, where the latter is mostly used by developers. Then, we created a new Azure AD tenant in the Azure portal, added our first user to it, and finally, cleaned up our resources and removed the Azure AD tenant.

After this introduction of all the different products and features that are offered by Azure, we are going to focus on registering applications inside our Azure AD tenant in the next chapter.

You can check out the following links for more information about the topics that were covered in this chapter:

• An overview of the Microsoft identity platform: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-overview
• Microsoft Secure Development Lifecycle (SDL): https://www.microsoft.com/en-us/securityengineering/sdl
• External Identities documentation: https://docs.microsoft.com/en-us/azure/active-directory/external-identities/