Skip to content

Application integration

Table of contents


A good place to start is the Microsoft Learn page Technical and feature overview of Azure Active Directory B2C.

When reading the section Identity experiences: user flow or custom policies know that in the current implementation we are leveraging custom policies for the User Journeys.

In Protocols and tokens the you will find the supported modern authentication protocols.

Getting started with application integration

As a developer it is beneficial to understand the Identity platform, how to perform integration with your application, and what is to be expected from a successful integration.

First step; register a new app registration.

Create an app registration or request one to be provisioned, if that is the process. The app registration details, including secret (if applicable), are required for the application to be able to communicate with the Identity platform.

See Creating or requesting an app registration to find out what information you must provide.

App registrations must be created by a privileged user (Application Developer, Application Administrator or more privileged role admin).
Usually, an app is either created in the Azure Portal or declared in infrastructure as code (IaC), using Terraform or Bicep, as a couple of examples.


The recommended way to manage app registrations is through infrastructure as code.
The IaC approach reduces the chance of configuration drift across environments.
Additionally, it may serve as an added backup as any manual change can be reverted back by running the pipeline again.
When using Terraform, for DEV environments, consider allowing manual changes (lifecycle -> ignore_changes) for redirect_uri, api and required_resource_access

App registrations

These pages contain lists of the available application registrations for the various environments:

Identity Experience Framework - custom policies


The Microsoft Identity platform introduces the policy parameter. With the policy parameter, you can use OAuth 2.0 to add policies to your app, such as sign-up, sign-in, and profile management user flows.

Source: Single-page application sign-in using the OAuth 2.0 implicit flow in Azure Active Directory B2C

When integrating an application with the B2C environment the policy parameter (SignUpSignInPolicyId) must be provided. This is a parameter that enables a user flow / custom policy (often called User Journey) to be executed by an application depending on the user initiated scenario.

For each environment these are the available custom policies:

Built-in policies (as opposed to custom policies) are also referred to as User flows, these are not used.

Custom policies are what the Identity Experience Framework use to define User Journeys. Custom policies support everything from easy to the most complex authentication and migration scenarios.

Here are some templates, one per environment, as an example of how to list the available User Journeys:

Authentication and authorization

With a policy in place and ready to be tested it is time to integrate your application with the Identity platform.
To update yourself, read through Identity platform: Authentication and Authorization.
This section describes the supported authentication protocols and also goes into the available OAuth2 grant flows that can be used.

In the sub-pages of this section, among other things, token validation is mentioned.
This is important to read and understand as security is always important to consider, and paramount for integrations like these.

Application integration examples

A quite common scenario, is to integrate (JavaScript) Single-Page architecture (SPA) applications.

These Microsoft Learn articles explain how to configure and integrate a web app and a web API:

There are also tutorials for integrating using other languages like Python and C# (ASP.NET / WPF app):

A common prerequisite, all samples must have an app registration. This is a re-occurring theme early on in the mentioned articles.

When using web APIs an application registration is also required for these. The APIs must be configured to expose one or more scopes and the web application must be granted appropriate delegated permissions (OAuth delegation).


Be aware of unsupported application types.

Finally, Recommendations and best practices for Azure Active Directory B2C.