Issue with Single Sign-On (SSO) Implementation in WPF Application

[JineshKamdar98]

Library version used

4.43.0.0

.NET version

.NET Framework 4.8

Scenario

PublicClient - desktop app

Is this a new or an existing app?

None

Issue description and reproduction steps

Hello everyone,

I'm encountering an issue with the implementation of Single Sign-On (SSO) in our WPF application, and I'd appreciate some guidance or insights from the community.

Here's a breakdown of our setup:

• We have a main WPF application that utilizes ADFS with MSAL for login purposes.
• Within this application, we've developed a custom WebView2 control, leveraging the PublicClientApplication to integrate with our custom control.
• Additionally, we provide support for hosting web applications within our WPF application. Recently, we incorporated an Angular (SPA) web application into our WPF environment, which also uses ADFS with MSAL for login.
• Our objective is to enable Single Sign-On (SSO) functionality in the hosted web application, utilizing the cache generated during the login process of our WPF application.

We've managed to achieve this integration successfully. However, we encountered a roadblock when attempting to implement automatic login in the WPF application under specific conditions. More specifically:

• We aim to automate the login process in the WPF application if a certain flag, let's call it "SingleSignOnUser," is set to True by the user. This is accomplished using the AcquireTokenSilent API provided by PublicClientApplication.
• The issue arises when calling AcquireTokenSilent: it doesn't display any prompts at the start of the WPF application, and consequently, our MSIS Auth Cookies are not being set in our custom WebView2 control. As a result, we're unable to achieve Single Sign-On (SSO) functionality in the hosted web application.
• It's important to note that we retain the user data folder in its path, and we're not deleting it along with the cache.

Has anyone else encountered a similar issue, or perhaps have insights into what might be causing this behavior? Any assistance or suggestions would be greatly appreciated!

Thank you in advance for your help.

Relevant code snippets

No response

Expected behavior

AcquireTokenSilent API should set MSIS Auth Cookies.

Identity provider

Microsoft Entra ID (Work and School accounts and Personal Microsoft accounts)

Regression

No response

Solution and workarounds

No response

[localden]

@JineshKamdar98 what would be helpful here is some minimally reproducible code sample. Can you please put one together and share it (can be its own repo)? It would help the team diagnose the specific scenario that you are implementing.

[JineshKamdar98]

@localden, we have one scenario where we need to get authentication result using AcquireTokenSilent API and the thing we observed is when we call this API, it can log users in successfully but it can't set MSIS Auth cookies in our custom WebView2 control and because of that when we render any web application with the use of same WebView2 control, it couldn't find any MSIS Auth cookies and couldn't able to do login while on the other hand when we call AcquireTokenInteractive API with our custom WebView2 control, it prompts for the user credentials and when users able to login successfully it sets MSIS Auth cookies in our custom WebView2 control and the result is users are able to log into web application which renders in the same WebView2 control.

Code sample:

Not Setting Cookies: authResult = await clientApp.AcquireTokenSilent(scopes, account).ExecuteAsync();

==============================================================================

Setting Cookies and works properly: var builder = clientApp.AcquireTokenInteractive(scopes).WithPrompt(Microsoft.Identity.Client.Prompt.SelectAccount);

builder = AcquireTokenInteractiveBuilderExtension.GetAcquireTokenInteractiveAsync(builder, enableCustomWebUi, CustomWebUI, webViewOptions);

authResult = await builder.ExecuteAsync();

In above code, CustomWebUI is our Custom WebView2 control.

[bgavrilMS]

Hi @JineshKamdar98 - you implemented your own browser based on WebView2 using extensibility. This is fine.

The problem with SSO is that WebView2 does not provide SSO by default, you have to enable it.

You do this by setting this property: https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2environmentoptions.allowsinglesignonusingosprimaryaccount?view=webview2-dotnet-1.0.2478.35

[JineshKamdar98]

@bgavrilMS , Thank you for your suggestion but I already tried enabling "AllowSingleSignOnUsingOSPrimaryAccount" setting but it didn't work with this scenario.

[iulico-1]

@JineshKamdar98 is ADFS auth critical to the repro? Sharing of ADFS cookies (MSISAuth) between your angular web app and WPF app can be problematic especially if they run in a separate process. If you don't use ADFS accounts just regular AAD are you able to get SSO between WPF and SPA ?

Do I understand correctly that if the user is prompted (as part of AcquireTokenInteractive) to re-auth then MSISAuth is dropped and SSO between WPF and SPA works ?

[JineshKamdar98]

@iulico-1 , I didn't try this on AAD. Also, to clear your understanding -

If user is prompted as a part of AcquireTokenInteractive then users are being asked to enter credentials and MSISAuth cookies are being set and we can achieve SSO between WPF and SPA.

The problem is in another scenario when we are calling AcquireTokenSilent which does not prompt the user about credentials so, MSISAuth cookies are dropped in this scenario and we can't able to achieve SSO between WPF and SPA.

Just to make clarification that my web app & WPF app both are running in same process.

[iulico-1]

@JineshKamdar98, our library was not designed to allow sharing of ADFS state x-app or x-webview. Looks like your scenario would require some logic to persist and share cookies with MSAL.net doesn't support.