Blog Post

Microsoft Entra Blog
3 MIN READ

Azure AD B2C now has JavaScript customization and many more new features

Alex Simons (AZURE)'s avatar
Feb 20, 2019

Howdy, folks!

 

I’m excited to announce that customizing your user flows with Azure AD B2C is now easier than ever with more features, including the general availability of our new portal experience and custom password complexity option. I’m also excited to share the public preview of the following features as well:

 

  • User templates—Create beautiful authentication experiences using default templates as a starting point for your branded UI.
  • JavaScript and page layout versions—Add more functionality to all your Azure AD B2C pages with your own custom JavaScript.
  • Identity provider access token passthrough—Send the access token from social identity providers back to the application.

 

Read on for more details and try out these features through the Azure portal.

 

New portal experience

With the new portal experience, you can easily create your next user flow. First released back in November, we're now making it generally available by releasing to all directories! We’ve seen some great improvements overall from your usage including:

 

  • Decreased task completion times for creating and editing user flows.
  • Higher completion rates when creating or updating existing user flows.

 

Users have also reported that they love using run user flow in place with the changes they’re making.
If you haven't had a chance to use the new UI yet, go to the Azure portal, and then go to the Azure AD B2C extension. Ensure you’re in your B2C directory and select User flows from the left-hand menu.

 

User flow overview in the new UI.

 

Custom password complexity
We’ve been cooking up this feature for a long time and are pleased that it’s now generally available. You can use this feature to lower password requirements to reduce user friction in signing up or increase the password complexity required to meet your compliance guidelines. Whatever requirement you enforce, you can help your users by having error messages that dynamically change as requirements are met. By default, password complexity is set to Strong for all newly created user flows. Read Configure complexity requirements for passwords in Azure Active Directory B2C to learn more.

 

Custom password complexity settings.

New user templates
The new user templates, in public preview, allow you to easily get started with creating beautiful sign in and sign up experiences for your users. You can access these templates through Page layouts. In the command bar, select Ocean Blue or Slate Gray. We’ve also hosted sample templates to help you get started.

 

Ocean Blue template for the sign up or sign in page.

JavaScript and page layout versions in public preview
We heard from you that you want to customize your sign in and sign up experiences using your own JavaScript and here you go! To use JavaScript, we enabled page layout versions. This lets you control the content on the page provided by the Azure AD B2C service and opt into updated versions. By having this control, you can use JavaScript reliably and ensure predictable behavior. Read about using JavaScript and page contract versions in a user flow to learn more.

 

Enabling JavaScript in Properties of your user flow.

Identity provider access token passthrough in public preview
We’re making it even easier for your application to leverage the power of social identity providers and their APIs. When a user signs in using an identity provider, like Facebook, your application can get the identity provider's access token passed through as part of the Azure AD B2C token. You will be able to use this access token to call the identity provider’s API, such as the Facebook Graph API. Read Pass an access token through a user flow to your application in Azure Active Directory B2C to learn more.

 

Identity provider access token in an Azure AD B2C token.

There’s a lot going on here! If you have any questions or feedback about these features, send us an email at aadb2cpreview@microsoft.com. You can also let us know what you think in the comments below. As always, we’d love to hear any feedback or suggestions you have.


Best regards,


Alex Simons (@Alex_A_Simons)
Corporate VP of Program Management
Microsoft Identity Division

Updated Jul 24, 2020
Version 11.0
  • adamstapleton's avatar
    adamstapleton
    Copper Contributor

    @ Alex_A_Simons
     

    Does the "Identity provider access token passthrough" mean that an Azure AD B2C Tenant can be used to access the Microsoft Graph API for a user that signed in with their AAD Tenant?

  • adamstapleton's avatar
    adamstapleton
    Copper Contributor

    @ Alex_A_Simons

     

    Just to calrify and remove any doubt in my mind. (I should have been more specific in my original post, sorry). Does this include full access to the MS Graph, specifically including access to the Office 365 portion of the MS Graph API?

     

    Is this enabling a scenario where I can sign in users from an AAD and then use their O365, for example their calendar? (With relevant permissions provided obviously)

     

    Essentially is the access token provided by B2C -> AAD passthrough the same access token spoken about here: https://docs.microsoft.com/en-us/graph/auth-overview

  • Steve_Khuu's avatar
    Steve_Khuu
    Copper Contributor

    Hey Alex!

    Great post! Glad to see that we can finally customize the page UI for the Sign In V2 flow.

    One thing we did notice is that in the Sign In V2 flow, it has inherited some behaviors from the SignInOrSignUp policy.
    Namely, if you create a user via the Azure Graph API and force them to change password in initial log in, the SignInOrSignUp policy does not recognize the user. Whereas the previous SignIn V1 flow, would recognize the user, go to the change password prompt page, then redirect to the appropriate application target.

    What would be nice is if the SignInV2 would behave the same as SignInV1, i.e. go to the change password prompt page the first time a new user signs in.

    Attached is a screenshot of the API call we're using.

     

    Noticable difference between signinv1 (red) and signinv2 (green)example payloadexample of what happens if we try to sign in using signinv2example of what happens if we try the same credentials on a signinv1 flow