The sample doesn't work for WPF apps targeting .Net Core 3.1, but with some tweaking I managed to authenticate with B2C to call my APIs.

.WithParentActivityOrWindow() doesn't exist and simply removing it will cause AcquireTokenInteractive() to do nothing when the button is clicked. So I changed redirectUri to http://localhost.

authResult = await app.AcquireTokenInteractive(App.ApiScopes)
                    //.WithParentActivityOrWindow(new WindowInteropHelper(this).Handle) // .Net Framework only?
                    .ExecuteAsync();

Doing the above will allow the WPF app to open the default internet browser to authenticate.

Is the above the only way for .Net Core 3.1 WPF right now? Or is there an equivalent embedded browser method like .WithParentActivityOrWindow()?

Hi parakhj,
I am being in trouble for testing the sample code from you . Eager to get your help

I download your sample code , and just replace the below:
` private static string Tenant = "xxxxx.onmicrosoft.com";
private static string ClientId = "xxxxxx-37e9-4e7d-8a05-xxxx";
public static string PolicySignUpSignIn = "B2C_1_SiUpIn";
public static string PolicyEditProfile = "B2C_1_SiPe";
public static string PolicyResetPassword = "B2C_1_SSPR";

    public static string[] ApiScopes = { "https://xxxxx.onmicrosoft.com/demoapi/demo.read" };
    public static string ApiEndpoint = "http://localhost:5000/hello";`

all of the parameters resource have been created in my aad b2c . when i startup the WPF , there comes the error:
Error Acquiring Token: Microsoft.Identity.Client.MsalServiceException: Returned user identifier does not match the sent user identifier
I feel that my( Sign In or Sign Up policy ) comes wrong but have no idea for the next correcting action.

can you make some suggestions . thanks

Best Regards
wenbo

Following the instructions here:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/tutorial-desktop-app?tabs=app-reg-preview#configure-the-sample

I've assigned my Redirect URI as the tutorial suggests:

However, the WPF app returns this:

That said, I'm finding the B2C setup for a desktop application quite complicated and confusing. I can run the sample app, but I'm having no success using the library with my own B2C tenant.

Currently this sample is referencing MSAL 2.7 version, is there any plan for you to upgrade the MSAL library version to latest 4.7 version?

Thanks,
Vedeevi

I have tried the sample code with our two types of users:

1. A user saved in Azure B2c
2. A user with a social account from Google

In both cases, I have an AuthenticationResult that looks like this
AccessToken = null
ExpiresOn = 0
IdToken = eyJ0eXAiOiJKV1QiLCJhbGciOi......
Scopes={}
TenantId=null
UniqueId=Valid User Id in AzureB2c
User=

The issue is that I am not getting any AccessToken, Hence I can not call my webApi
I have even created a new Application in Azure B2C, and I still get the same exception.

The Experimental library of Microsoft works on our Azure B2C, so I wonder if this is not related to the implementation itself ?

Any help would be appreciated.

Hi,

I have been using this sample but when I create an executable file and install it on another machine the errors begin. When I install in on my own PC everthing is fine...

Here is the error message:

Error Acquiring Token: System.InvalidOperationException: Sequence contains no elements at System.Linq.Enumerable.Max[TSource](IEnumerable1 source) at Microsoft.Identity.Client.TokenCache.CalculateSuggestedCacheExpiry() at Microsoft.Identity.Client.TokenCache.d__59.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Identity.Client.Cache.CacheSessionManager.d__10.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Identity.Client.Internal.Requests.RequestBase.d__16.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Identity.Client.Internal.Requests.InteractiveRequest.d__8.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Identity.Client.Internal.Requests.RequestBase.d__12.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Identity.Client.ApiConfig.Executors.PublicClientExecutor.d__2.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter1.GetResult() at active_directory_b2c_wpf.MainWindow.<SignInButton_Click>d__1.MoveNext() in C:\Users***\Desktop\active-directory-b2c-dotnet-desktop-msalv3\active-directory-b2c-wpf\MainWindow.xaml.cs:line 36

So what am I doing wrong? And can anybody get the sample app working after they have created an executable file from it?

Google - fails
Facebook

We should default to the system browser.

GitHub

I tried to use it with my own tenet. it works when i click sign in but if i clicked sign up , it shows me that error

Steps to reproduce:

1. Call API and see the current display name returned
2. Edit profile and change display name
3. Call API

Results:
previous display name is returned

msalv3 branch, fresh clone this morning, open solution, build. Fails because of missing nuget packages. Determined it is because there is a packagereference in the csproj. (off-topic: there is a version mismatch between the one in packages.config and the package reference). Delete the PackageReference in csproj, build, and now it fetches all the nuget packages to ..\packages. But it fails to build because one of the nuget packages requires PackageReference (the one I deleted). So I put it back, and now build succeeds because i previously downloaded the nuget packages.

make sure you don't use custom domains.. only xxx.onmicrosoft.com

In the readme of this repo here https://github.com/Azure-Samples/active-directory-b2c-dotnet-desktop#step-4-register-your-native-app the " register your native app in your B2C tenant" redirects to the web app instructions instead, so I think it should be changed to redirect in the native app (https://docs.microsoft.com/en-gb/azure/active-directory-b2c/add-native-application?tabs=app-reg-ga)

I am using the following code:

try
{
    authResult = await app.AcquireTokenInteractive(App.ApiScopes)
                        .WithUseEmbeddedWebView(false)
                        .WithParentActivityOrWindow(new WindowInteropHelper(this).Handle)
                        .ExecuteAsync();
}
catch (MsalClientException ex)
{
    msg = $"Error Acquiring Token: {ex}";
}

I want to handle the case where the user is prompted to the login page, but then closes it or navigates away. For this I have observed two conflicting behaviours being documented.

On the one hand it is stated on the following wiki that MSAL will throw a MsalClientException with the error code authentication_canceled , if when calling AcquireTokenInteractive(), the user closes the process or hits the back button on their browser.
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/exceptions#common-exceptions

On the other hand on azure documentation it is stated that MSAL.NET cannot detect if the user closes the login page or navigates away.
https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-net-web-browsers#system-browser-experience-on-net

I have confirmed that my code exhibits the later behaviour, so no exception is thrown. If that is the case and MSAL.NET cannot detect such browser behaviour, then is there a valid scenario, where the login page is closed and the program throws a MsalClientException?

Hi there! This is a great sample that was straight forward to connect to my own B2C tenant and get working quickly.

As I start to experiment with it however, I am running into some issues. I would like to be able to package and distribute an application protected against B2C as a .msix. Having done so, I am running into an issue where an installed copy of the sample is not permitted access to the token cache.

System.UnauthorizedAccessException: Access to the path 'C:\Program Files\WindowsApps\wpfInstallerTest_1.0.3.0_x64__3ae7ag8q269pa\active-directory-b2c-wpf\active_directory_b2c_wpf.exe.msalcache.bin' is denied.```

Is there something that I need to do to make sure that the app can get access to the token cache of my distributed users? It is currently preventing a successful sign in.

When Attempting to Sign-In I receive the following Error.

Error Acquiring Token:
Microsoft.Identity.Client.MsalServiceException: AADB2C90079: Clients must send a client_secret when redeeming a confidential grant.
Correlation ID: 12179f8b-25b5-4e26-a8be-2357a203af36
Timestamp: 2019-04-04 23:21:40Z

   at Microsoft.Identity.Client.OAuth2.OAuth2Client.CreateErrorResponse(HttpResponse response, RequestContext requestContext)
   at Microsoft.Identity.Client.OAuth2.OAuth2Client.CreateResponse[T](HttpResponse response, RequestContext requestContext, Boolean addCorrelationId)
   at Microsoft.Identity.Client.OAuth2.OAuth2Client.<ExecuteRequestAsync>d__10'1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Identity.Client.OAuth2.OAuth2Client.<GetTokenAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Identity.Client.Internal.Requests.RequestBase.<SendHttpMessageAsync>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Identity.Client.Internal.Requests.RequestBase.<SendTokenRequestAsync>d__22.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Identity.Client.Internal.Requests.InteractiveRequest.<ExecuteAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Identity.Client.Internal.Requests.RequestBase.<RunAsync>d__16.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Identity.Client.PublicClientApplication.<AcquireTokenForUserCommonAsync>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Identity.Client.PublicClientApplication.<AcquireTokenAsync>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter'1.GetResult()
   at active_directory_b2c_wpf.MainWindow.<SignInButton_Click>d__1.MoveNext() in C:\Users\r\source\repos\active-directory-b2c-dotnet-desktop-master\active-directory-b2c-wpf\MainWindow.xaml.cs:line 34
	ErrorCode: invalid_request
	StatusCode: 400
	Claims: 

Please Help. Has some sort of token expired which I need to refresh?

At this point in time, after changing the demo to use my own B2C coordinates, I'm getting logins with the interactive flow, but the bearer token is null.

APIScopes looks like this (tenant urls are incorrect here (I'm hiding my tenant name) but they work in the demo, all the way through the interactive authentications):

        public static string[] ApiScopes = { $"https://{Tenant}.onmicrosoft.com/api/user_impersonation" };
        public static string ApiEndpoint = "https://graph.microsoft.com/";
        public static string AuthorityBase = $"https://{Tenant}.b2clogin.com/tfp/{Tenant}/";

What I'm really trying to do is use graph.microsoft.com/v1.0/Me, which I thought would be simple, given the very, very strong urging by Microsoft to switch to Graph for B2C. Alas, no bearer token, no Graph. (If I can get it working I'll likely push the branch so that there's a decent simple interactive desktop demo for B2C Graph)

I'm not entirely sure I've got this understood correctly, but without a bearer token I can't even get a good error message.

If you have authenticated to a wpf app with multiple accounts (during different sessions), it is possible to make a token refresh request that returns a bearer token for the wrong account.

I assume that this is due to the accounts.FirstOrDefault() argument in the token refresh below.

        public async Task PostScreeningRecord(string url, ScreeningRecord screeningRecord)
        {
            AuthenticationResult authResult = null;
            var app = App.PublicClientApp;
            var accounts = await app.GetAccountsAsync(App.PolicySignUpSignIn);

            try
            {
                authResult = await app.AcquireTokenSilent(App.ApiScopes, accounts.FirstOrDefault())
                    .ExecuteAsync();
            }

Presumably, I need to be passing in an argument that specifies the account to refresh the token for. It was my assumption that the default would be the account that is currently signed in, but this doesn't necessarily appear to be the case.

Is there documentation, or a recommended implementation for passing a specified account argument?

Hello, we are trying to migrated our application which contains the most authentication concept from this example to .net 5 WPF (base app project built on .net framework "4.x").

In our actual app it works fine, when we migrate the app to .net 5, the registration returns always an exception (some informatons with url redirect etc...).

Also the method "WithParentActivityOrWindow" is not available in .net 5 and has to be removed from the code.

Note: #60 (closed issue) has similar issue

We have changed several code but are not able to make it run under .net 5.. We have also used for verification purpose the credential from this demo, but this also fails.

Can you update the demo code for net 5 compatibility ?

When executing AcquireTokenAsync in sample active-directory-b2c-dotnet-desktop the AccessToken is missing and IdToken is set.
Not sure if this is correct behavior.
Assuming that IdToken contains JWT, then the sample should use IdToken instead of AccessToken in following line:

ResultText.Text = await GetHttpContentWithToken(App.ApiEndpoint, authResult.AccessToken);

Last but not least, for some reason encoded token in IdToken seems not to be correct.
Getting following after decoding:

{"typ":"JWT","alg":"RS256","kid":"X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"}�⦗炣㓓�#�#㳃₦榢#㓓�#�#Ss�₧fW"#⣒ア¦緲#⦇GG�3Ⲷƶv梦֖7&綶gF榆榒涶ҳsSc㖳&RӦS��ӆ#&B֓v#b֦S&�#V63�&�r磢ゲ"§7V"#⣦f3�F3�"֓㶢ӃsVRӃ㆒ӃS&C㶦F3S梢¦�VB#⣦3㓓��RӖcCbӆSVRӖ#�RӖ6C

We noticed this happening yesterday with our main product that uses b2c. I thought I'd try with your sample app and I get the same behaviour on a number of different machines. When I try to login, I just get a blank popup with redirecting inside it. A few things to note

(a) It's impacting our customers not just internal users
(b) It doesn't seem to happen on a clean machine (I created one in an Azure vm)
(c) It doesn't seem to happen with a new user account

The big difference that gets everything working though it to change from login.microsoftonline.com to b2clogin.com

    private static readonly string Tenant = "mytenantname.onmicrosoft.com";
    private static readonly string AzureAdB2CHostname = "mytenantname.b2clogin.com";

The MSALv3 branch works with simple username-password login, but it gives a redirect URI error when I want to use Microsoft Account login:

invalid_request: The provided value for the input parameter 'redirect_uri' is not valid. The expected value is a URI which matches a redirect URI registered for this client application.

I have tracked down the issue to the BaseAuthority field in App.xaml.cs. It should use the new b2clogin.com domain according to the docs as the B2C Microsoft Account config also uses the b2clogin domain.

When we create b2c tenant as referenced in readme (https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-get-started), the tenant is created without V2 endpoint.
https://login.microsoftonline.com/common/oauth2/v2.0/authorize

it provides only v2 endpoint: https://login.microsoftonline.com/common/oauth2/authorize

However sample described here uses 'Microsoft.Identity.Client', which uses v2 endpoints.

It would be useful to add some documentation on how to configure the URI scheme in the .NET app, which will eventually used in the production scenario as the redirect uri instead of the localhost. For example, how we can configure this com.onmicrosoft.contosob2c.exampleapp://oauth/redirect

This example fails to find my azure account but finds my other Microsoft accounts. What gives here ? I can log in to my azure account no problem from the azure.portal.com but this example code tells me that no account exists ?

I'm getting started with authenticating my app with MSAL. Now I'm copying and pasting from this sample. There's redundancy, however, that I don't want to carry over to my app.

I think that acquiring a token interactively is the same whether it's upon sign-in or in response to an MsalUiRequiredException exception thrown during an API call. In my app, I'd like this to be a common GetTokenInteractively method that's called in the two scenarios.

In this sample, I notice that .WithPrompt(Prompt.SelectAccount) is called upon sign-in but not for an API call.

According to WithPrompt's docs, "The default is Microsoft.Identity.Client.Prompt.SelectAccount". So that means all the .WithPrompt(Prompt.SelectAccount) lines have no effect and can be safely removed, right? That would make the code for interactively acquiring tokens more similar between the sign-in and API call scenarios.

One remaining difference between these two scenarios in the sample app, is that the sign-in scenario handles the AADB2C90118 error to run the Forgot Password user flow. Could that also apply to the API call scenario? A user could forget her password while trying to call an API. Even if not, having that error handling code in the common method wouldn't hurt the API call scenario, right?

Please update the whole sample to use the new version of MSAL (4).

There are breaking changes from MSAL 3 to 4.

This sample has helped me get a fairly good understanding of how to manage authenticated users and sessions on a local Windows 10 app. One thing that I would like to be able to do however, is persist the authenticated session.

Current Behavior

• Login to application
• Acquire id token and access token
• Refresh access token as necessary
• Close app -> authenticated session ends.

Desired Behavior
I would like to be able to achieve the behavior above plus be able to open the application again after closing it and still be authenticated.

Right now, authenticated session ends when I close the app. How would I go about chaining this behavior?

I am doing the following steps

1. Execute this code

var authResult1 = await app.AcquireTokenInteractive(App.ApiScopesBasic)
                   .WithUseEmbeddedWebView(false)
                    .WithParentActivityOrWindow(new WindowInteropHelper(this).Handle)
                    .ExecuteAsync();

which is in the SignInButton_Click code of this sample.
an id token is returned, which includes several claims including for example the user's first name - which right now is "name1".

2. After the above call is done, I manually update the information of the user in the azure portal (eg. update the first name from "name1" to be "name2"). In reality, I would not update the user's info in the portal but I could have some other application updating the user's information using graph API while the user still has a valid refresh token.

3. Do this call

var authResult2 = await app.AcquireTokenSilent(App.ApiScopesBasic, accounts.FirstOrDefault())
                        .WithForceRefresh(true)
                        .ExecuteAsync();

in the id token of this auth result, I still get the "name1" as in the call of step 1 (instead of the "name2" as updated in step 2). If instead of acquiring the token silently, I do an interactive one then I will get the correct name.

Is the .WithForceRefresh(true) not enough? How can I force get the user's latest information without requiring user interaction?

thanks

steps to reproduce:

1. Click on sign-in button
2. Close the window
3. Note how the "API Call Results" textbox shows how the user cancelled authentication
4. Click sign-in and successfully sign-in

Results:
The API Call Results textbox still shows the exception from the user cancelled authentication

Expected:
Textbox to be cleared