As you may have come to realize OAuth and OIDC are relatively heavy concepts. However, being able to securely authenticate and authorize your end users is a necessary part of any web applications that contain data with restricted access.
Manually creating your own service for authenticating and authorizing is something that is possible, but risky. No matter how talented you and your team may be it is difficult to compete with a company that dedicates as many resources to security as Microsoft does. By using Microsoft Azure AD B2C the risk of implementing authentication or authorization incorrectly is mitigated completely.
Let’s consider the different entities involved in the system we will be building and using:
The client, provider and user interactions are managed by a special kind of entity called an authority. The authority in this case is Azure AD B2C which acts as the bridge between a client, a provider and a user.
Azure AD B2C is the authority over all authentication and authorization in the system. AADB2C can manage customer identities for authentication as well as securing interactions between registered applications. In the latter case two applications are registered, one as a client and the other as a provider that is protected by AADB2C.
In the examples throughout this chapter the entities we will be working with are:
Let’s cover some of the essential components we will be using to configure our AADB2C service. You will hear about these components many times in the upcoming lessons. You can read a more detailed coverage of AADB2C in this Microsoft article.
Note
A confusing aspect of AADB2C is that it can behave as two different roles depending on the interaction it is managing:
The tenant directory is the central component of an AADB2C service. The tenant is an Active Directory (AD) instance that can be used to manage both identity (authentication) and access (authorization). You can think of the Active Directory side of AADB2C as a resource server for identity resources.
The Business to Customer (B2C) aspect of AADB2C relates to how the AD instance supports an organization comprised of both customer and business accounts. In AADB2C customers can create accounts using different provider services like Microsoft, GitHub or LinkedIn.
Note
Because AADB2C is designed to integrate with customers it also supports a local account provider that allows customer to create accounts with their own username or email and password. This is how we will be using AADB2C in the upcoming lessons.
Within a tenant directory you can register applications that you allow to integrate with your organization. Registered applications can include applications within your organization or those from a trusted third party.
The role (identity or authorization) that AADB2C will assume is based on how the application is configured. An application can be configured as:
An application configured as a client is a consumer of the user’s identity data. For example, in our first walkthrough we will register the Coding Events API to be a client application that uses AADB2C as an identity provider to authenticate users with OIDC.
A provider application is configured to receive requests for its own resources and requires authorized requests containing an access token. AADB2C manages the OAuth process of granting an access token to another registered client application which authorizes it to consume resources from the provider.
Note
A registered application can be configured to act as both a client and provider. For example, our Coding Events API will act as both a:
In the OAuth walkthrough you consented the Visual OAuth application to use the read:user scope and access your private GitHub user data. When configuring a provider application in your AADB2C service you will expose scopes for it. These scopes control how other registered client applications can access the underlying data.
In the upcoming access token walkthrough you will get a chance to work behind the scenes to define your own scope. We will configure a user_impersonation scope that the Postman client application will use to make authorized requests on behalf of a user.