This page is for MSAL 3.x

If you are interested in MSAL 2.x, please see AAD B2C specifics in MSAL 2.x

You can use MSAL.NET to sign-in users with social identities by using Azure AD B2C. AAD B2C is built around the notion of policies. In MSAL.NET, specifying a policy translates to providing an authority.

• When you instantiate the Public client application, you need to specify the policy in authority
• When you want to apply a policy, you need to call an override of AcquireTokenInteractive containing an authority parameter

The authority to use is https://login.microsoftonline.com/tfp/{tenant}/{policyName} where:

• tenant is the name of the Azure AD B2C tenant,
• policyName the name of the policy to apply (for instance "b2c_1_susi" for sign-in/sign-up).

The current guidance from B2C is to use b2clogin.com as the authority. For example, $"https://{your-tenant-name}.b2clogin.com/tfp/{your-tenant-ID}/{policyname}". For more information, see this documentation.

// Azure AD B2C Coordinates
public static string Tenant = "fabrikamb2c.onmicrosoft.com";
public static string ClientID = "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6";
public static string PolicySignUpSignIn = "b2c_1_susi";
public static string PolicyEditProfile = "b2c_1_edit_profile";
public static string PolicyResetPassword = "b2c_1_reset";

public static string AuthorityBase = $"https://fabrikamb2c.b2clogin.com/tfp/{Tenant}/";
public static string Authority = $"{AuthorityBase}{PolicySignUpSignIn}";
public static string AuthorityEditProfile = $"{AuthorityBase}{PolicyEditProfile}";
public static string AuthorityPasswordReset = $"{AuthorityBase}{PolicyResetPassword}";

When building the application, you need to provide, as usual, the authority, built as above

application = PublicClientApplicationBuilder.Create(ClientID)
               .WithB2CAuthority(Authority)
               .Build();

Acquiring a token for an Azure AD B2C protected API in a public client application requires you to use the overrides with an authority:

IEnumerable<IAccount> accounts = await application.GetAccountsAsync();
AuthenticationResult ar = await application .AcquireToken(scopes, parentWindow)
                                            .WithAccount(GetAccountByPolicy(accounts, policy))
                                            .ExecuteAsync();

with:

• policy being one of the strings above (for instance PolicySignUpSignIn)

• GetAccountByPolicy(IEnumerable<IAccount>, string) is a method that finds an account for a given policy. For instance:

  private IAccount GetAccountByPolicy(IEnumerable<IAccount> accounts, string policy)
  {
   foreach (var account in accounts)
   {
    string userIdentifier = account.HomeAccountId.ObjectId.Split('.')[0];
    if (userIdentifier.EndsWith(policy.ToLower()))
     return account;
   }
   return null;
  }

Applying a policy (for instance letting the end user edit their profile or reset their password) is currently done by calling AcquireTokenInteractive.

Note that in the case of these two policies you don't use the returned token / authentication result.

When you want to provide an experience where your end users sign-in with a social identity, and then edit their profile you want to apply the B2C EditProfile policy. The way to do this, is by calling AcquireTokenInteractive with the specific authority for that policy and a Prompt set to Prompt.NoPrompt to avoid the account selection dialog to be displayed (as the user is already signed-in)

private async void EditProfileButton_Click(object sender, RoutedEventArgs e)
{
 IEnumerable<IAccount> accounts = await app.GetAccountsAsync();
 try
 {
  var authResult = await app.AcquireToken(scopes:App.ApiScopes)
                               .WithAccount(GetUserByPolicy(accounts, App.PolicyEditProfile)),
                               .WithPrompt(Prompt.NoPrompt),
                               .WithB2CAuthority(App.AuthorityEditProfile)
                               .ExecuteAsync();
  DisplayBasicTokenInfo(authResult);
 }
 catch
 {
  . . .
}

For more details on the ROPC flow, please see this documentation.

This flow is not recommended because your application asking a user for their password is not secure. For more information about this problem, see this article.

By using username/password you are giving-up a number of things:

• core tenants of modern identity: password gets fished, replayed. Because we have this concept of a share secret that can be intercepted. This is incompatible with passwordless.
• users who need to do MFA won't be able to sign-in (as there is no interaction)
• Users won't be able to do single sign-on

In your AzureAD B2C tenant, create a new user flow and select Sign in using ROPC. This will enable the ROPC policy for your tenant. See Configure the resource owner password credentials flow for more details.

IPublicClientApplication contains a method called

AcquireTokenByUsernamePassword(
            IEnumerable<string> scopes,
            string username,
            SecureString password)

This method takes as parameters:

• The scopes to request an access token for
• A username
• A SecureString password for the user

Remember to use the authority which contains the ROPC policy.

• This only works for local accounts (where you register with B2C using an email or username). This flow does not work if federating to any of the IdPs supported by B2C (Facebook, Google, etc...).

If you are a B2C developer using Google as an identity provider we recommand you use the system browser, as Google does not allow authentication from embedded webviews. Currently, login.microsoftonline.com is a trusted authority with Google. Using this authority will work with embedded webview. However using b2clogin.com is not a trusted authority with Google, so users will not be able to authenticate.

We will provide an update to the wiki and this issue if things change.

MSAL.Net supports a [token cache] (https://docs.microsoft.com/en-us/dotnet/api/microsoft.identity.client.tokencache?view=azure-dotnet). The token caching key is based on the claims returned by the Identity Provider. Currently MSAL.Net needs two claims to build a token cache key: :

1. tid which is the Azure AD Tenant Id and
2. preferred_username

Both these claims are missing in many of the Azure AD B2C scenarios.

The customer impact is that when trying to display the username field, are you getting "Missing from the token response" as the value? If so, this is because B2C does not return a value in the IdToken for the preferred_username because of limitations with the social accounts and external identity providers (IdPs). Azure AD returns a value for preferred_username because it knows who the user is, but for B2C, because the user can sign in with a local account, Facebook, Google, GitHub, etc...there is not a consistent value for B2C to use for preferred_username. To unblock MSAL from rolling out cache compatibility with ADAL, we decided to use "Missing from the token response" on our end when dealing with the B2C accounts when the IdToken returns nothing for preferred_username. MSAL must return a value for preferred_username to maintain cache compatibility across libraries.

The suggested workaround is to use the [Caching by Policy] (https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/AAD-B2C-specifics#acquiring-a-token-to-apply-a-policy)

Alternatively, you can use the tid claim, if you are using the [B2C custom policies] (https://aka.ms/ief), because it provides the capability to return additional claims to the application. To learn more about Claims Transformation

One option is to use the "name" claim as the preferred username. The process is generally mentioned in this B2C doc ->

"In the Return claim column, choose the claims you want returned in the authorization tokens sent back to your application after a successful profile editing experience. For example, select Display Name, Postal Code.”