Understanding 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.