End User Experience in AD B2C?

What about Microsoft’s frontend design that we didn’t like?

User flows didn’t have much configuration, but the custom policies have a way to essentially “inject” your own HTML and JavaScript into Microsoft’s pages.

To do that you have to host the HTML (or CSS, CSHTML etc.) file somewhere (usually in Azure Storage Account) and make it available to the internet.

You would then configure it this way in the Building Blocks section of the policy:

<BuildingBlocks>
  <ContentDefinitions>
    <ContentDefinition Id="api.signuporsignin">
      <LoadUri>https://your-storage-account.blob.core.windows.net/your-container/customize-ui.html</LoadUri>
      <RecoveryUri>~/common/default_page_error.html</RecoveryUri>
      <DataUri>urn:com:microsoft:aad:b2c:elements:unifiedssp:1.0.0</DataUri>
      <Metadata>
        <Item Key="DisplayName">Signin and Signup</Item>
      </Metadata>
    </ContentDefinition>
  </ContentDefinitions>
</BuildingBlocks>

This is good and works well.

You change pretty much anything HTTP/CSS-wise. You can even do a simple JavaScript injection, which can change even more. You can hide certain buttons in certain situations or have live input validation where there usually isn’t one (for example, for national identification numbers). But in the end, you are only changing the layout, adding logos, using different colors, moving around what already exists, etc.

You must keep what each button does: How stuff gets called or internal business logic because you are referencing Protocol, which is some internal Microsoft library that makes all the decisions for you, and unless the Protocol allows configuration with metadata, you are stuck with how it’s designed.

For example, Microsoft’s default email verification works by inputting your email, clicking on Send Verification code (on the same page), and then inputting your code from your email and clicking verify (still on the same page). It happens even though they have the same multistep/multipage phone verification as every other website.

I would also like to mention that Microsoft handles email and phone verification independently, and you don’t have to set up any phone number or email accounts. Hence, costs are reduced dramatically, and you are not dependent on third-party email/phone solutions, which is awesome and works great until it doesn’t. We had an issue where sometimes when the user wanted to verify their email or phone, no SMS or email would arrive (and yes, we checked the spam folder). This was possibly a local error for the Czech Republic, and we believe it was resolved with an update, but we are not sure because this solution is a huge black box with next to no logs or telemetry. Fortunately, the issue didn’t occur again.