Microsoft Azure Active Directory B2C Primer: Part 1

Microsoft’s Customer Identity and Access Management solution, Azure Active Directory B2C, is rapidly being adopted as businesses upgrade their legacy cloud application with Modern Authentication solutions.

This blog post is the first in a series to help understand how Azure Active Directory B2C (Azure AD B2C) works, and the components involved. We will go beyond simple examples and explain how it works and how to utilize custom policies with the Identity Experience Framework.

Modern Authentication is the utilization of Open ID Connect (OIDC). OIDC is a standards protocol built as an extension to OAuth 2.0. In the coming weeks I will be writing a blog on those details, but for now there are many resources that can be found that explain OIDC. In simple terms, it allows one protected application to trust another protected application, and once that trust is verified a Token (cookie) that represents the user is returned with their claims, or attributes, attached.

Create your Azure AD B2C instance and register an application

The first step to understanding the solution is to create your own B2C instance. It’s a simple process that can be done by following these instructions.

Once that is done, the next step is to register an application. For our purposes you don’t need to create a client secret. The sixth step – defining the flow as Implicit or Implicit grant – is important. What does this mean? Look here.

Implicit Grant will send back a Token without the back end verification one can get using the other flows. This is good for demonstrations and Single Page Applications (SPAs) written in JavaScript, but if you intend on calling a back end API with an access token, this is not the thing to do.

The next step is to create a user flow and test out the experience to see what claims are returned via jwt.ms. Your application should consume the claims obtained once a user logs in, and app authorization and customization can be done utilizing these.

Go to your application via App registrations (Preview) and go to endpoints. Select the OpenID Connect configuration endpoint (v2) and replace the {policy} with your policy, and enter this in a browser. You will get the profile specific endpoints, and the claims associated with that endpoint. This is called the metadata endpoint, and contains information that applications can use to know how to obtain tokens.

In the next post we will discuss custom profiles and how they extend B2C’s functionality. Stay tuned!