I already have covered how to authenticate users in WPF application, using Azure AD B2C and MSAL. The most annoying part to me in that implementation was – the sign in button click was opening the default browser on the user’s system.

So, let’s have a look at Custom Web UI feature and how does it help.

Embedded vs System Web UI

Web browsers are required for interactive authentication

MSAL.NET is a library targeted to work with multiple platforms. But this library also has platform specific code to host the web browser to facilitate the interactions. This platform specific implementation is called as Embedded UI.

In addition to embedded UI, the library MSAL.NET also allows to open the system browser for interactive authentication.

For some of the platforms, the embedded UI is not implemented yet in MSAL.NET. So, on those platforms, if you trigger sign in operation, it opens system’s default browser.

Now, you might have guessed why .NET Core WPF application opens system’s default browser for interactive login. It’s because the embedded UI is not implemented yet.

Below is the data borrowed from MSAL documentation and it shows which browsers are supported and which UI is triggered by default.

For platforms which have both embedded as well as system browser support, it is recommended to use the default UI. But if you wish to use non-default UI because of some reasons, that can be achieved by specifying WithUseEmbeddedWebView(bool) API.

Why Custom Web UI ?

Some of the platforms which do not support embedded UI open the system browser for performing interactive authentication. Now, the system browser is a different application/process on user’s machine.

So, the actual application (in our case .NET Core Wpf App), does not have any control on what user does in the browser. So, it may not look good from user experience perspective to open system browser just for authentication.

So, MSAL.NET provides extension point, you can create your own web UI, which will be used by MSAL for interactive logins.

We have to implement an interface ICustomWebUi which will let the MSAL know which custom UI should be used.

What are we going to do ?

We already have .NET Core WPF App which is using Azure AD B2C for authentication. It opens system browser as mentioned before.

So, we will add a WPF window which has web browser and that web browser will interact with Azure AD B2C authority. Then we will implement ICustomWebUi to plug everything together

Let’s get started.

Prerequisites

For following all steps in this article, we will need Azure Subscription. If you don’t have an Azure subscription, create a free account before you begin.

We will also need instance of Azure AD B2C instance. We will also need API and Angular App already registered in that instance.

Below is the list of those posts which explains all the steps to get there:

• Create Azure AD B2C instance
• Create user flows in Azure AD B2C
• Azure AD B2C and MSAL with .NET Core WPF App

You should have Azure AD B2C instance, let’s say samplead.b2clogin.com and user flows B2C_1_SignUpSignIn for signing up or signing in the application.

You will also have a .NET core WPF app which is using Azure AD B2C for authentication, but opening system’s default browser for asking the credentials.

Custom Login Window

In our WPF application, let’s add a new window and name it CustomLoginWindow. In xaml script. let’s add the default WebBrowser control.

Please note that any WebBrowser control can be used, including Chromium Embedded Browser. But we are choosing the default control just to keep the things simple.

Also, subscribe to Loaded and Closed events of this window. Loaded event will start the navigation to authorization URI, while Closed event will try to cancel all the operations and close the panel.

Below is the xaml code for the file:

Below is the code behind for the file:

Implement ICustomWebUi

ICustomWebUi is an interface from MSAL, an extension point, that can be used to hook the custom login view.

This implementation is simple. In summary, it has a method which is invoked via MSAL. This method takes few parameters like authorization URI, redirect URi, cancellation token.

These parameters and some additional parameters which were set while initializing this type (like title, hight, width and owner of window) are then used to instantiate the CustomLoginWindow and ShowDialog method is used to render it.

Below snippet shows the complete implementation:

Plug it in with MSAL

As mentioned earlier, this screen is only for interactive authentication.

So, when the AcquireTokenInteractive API is used, use WithCustomUI API and specify the EmbeddedCustomWebUI created in previous step.

Also, specify current instance as input parameter. This current window will be used as owner for the sign in window.

Below is the code snippet showing the same. This change is required to be done at all places where interactive authentication API is used.

Error

Then, when I tried to run the application, I got below error when I clicked on sign in button.

AADB2C90058 – The provided application is not configured to allow public clients

Resolution

So, I went to Azure AD app registration for WPF and enabled the Treat application as a public client input and set it to Yes.

Azure AD B2C now supports localhost URIs so there is no need to enable any other redirect URIs for .NET Core WPF application.

Run and Verify

Now, when we run the application and click on sign in button, our custom window opens instead of the system’s default web browser as shown in below image.

So, we have successfully managed to show our own custom window which loads the login screen from Azure AD B2C. I hope you enjoyed the article. Let me know your thoughts.