I need to be able to set "AllowSingleSignOnUsingOSPrimaryAccount = true" for single sign on in a UWP app

[jeremiahjordanisaacson]

Describe the feature/enhancement you need

I read the below and it appears I can't do this today. It seems like a pretty critical feature especially with the "Device ID" block for Azure AD. Please let me know if there is a work around for a C# UWP app that wants to use WebView2 with Single Sign On.

API limitations

The following classes aren't accessible in WinUI 2 or WinUI 3:

• CoreWebView2EnvironmentOptions
• CoreWebView2ControllerOptions

The scenario/use case where you would use this feature

This would allow application users to automatically sign into a modern application. Not having this feature means that I have to revert to building a .NET WPF app. I don't think that's the direction you want developers to go.

How important is this request to you?

Critical. My app's basic functions wouldn't work without it.

Suggested implementation

Fix this:

API limitations

The following classes aren't accessible in WinUI 2 or WinUI 3:

• CoreWebView2EnvironmentOptions
• CoreWebView2ControllerOptions

What does your app do? Is there a pending deadline for this request?

Access an internal site that I don't own but requires corporate AAD to access. ASAP

AB#48742778

[aluhrs13]

@liminzhu / @champnic - Do we have a commandline flag that we can recommend they set through the environment variable?

[nishitha-burman]

There is a workaround discussed here: #747. Does this work for you?

[jeremiahjordanisaacson]

I tested the workaround, and it didn't work for my scenario. Any ETA for a proper fix?

[pieths-ms]

@jeremiahjordanisaacson Regarding adding support for CoreWebView2EnvironmentOptions and CoreWebView2ControllerOptions to WinUI2, this is something that we are tracking internally but, at the moment, it doesn't look like we will be able to address this anytime soon.

From a functional point of view,

CoreWebView2EnvironmentOptions options = new CoreWebView2EnvironmentOptions()
{
    AllowSingleSignOnUsingOSPrimaryAccount = true
};

and,

Environment.SetEnvironmentVariable("WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS", "--enable-features=msSingleSignOnOSForPrimaryAccountIsShared");

essentially do the same thing under the hood. They are just two different ways to enable the same feature.

It looks like there may be a problem with SSO and MSA accounts in UWP apps (AAD enterprise login is working as expected though). Are you seeing the issue with MSA accounts (ie. when navigating to sites like https://login.live.com)?

[jeremiahjordanisaacson]

@pieths-ms I'm getting the "You can't get there from here." message when attempting to use the code suggested. In my WPF app, it works though. Any ETA on a fix?

Code I used:
Environment.SetEnvironmentVariable("WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS", "--enable-features=msSingleSignOnOSForPrimaryAccountIsShared");

Error message:

Error is due to the "Device ID" not getting passed along:

[pieths-ms]

@jeremiahjordanisaacson, what type of account are you using for sign-in: MSA or AAD? Are you seeing the error with both types of accounts or just one of them?

[jeremiahjordanisaacson]

@pieths-ms AAD.

[pieths-ms]

@jeremiahjordanisaacson Have you enabled the following capability in your UWP app?

enterpriseCloudSSO (Enterprise Cloud Single Sign On: The enterpriseCloudSSO capability allows apps to use single sign on with Azure Active Director (AAD) resources inside a hosted web view control).

See here for more details regarding enterpriseCloudSSO and other related capabilities.

Depending on what your app needs with respect to authentication, the following may also be useful: <uap:Capability Name="enterpriseAuthentication"/>

[jeremiahjordanisaacson]

@pieths-ms It's not working. I was missing the suggestion above for the enterprise auth setting, so I made the update, tested, and no luck. I attempted to create an entirely new project from scratch following all recommended guidance but alas still not working. Any idea how to resolve?

Notice it's added:

Notice, also added the environment setting:

Notice, the WebView2 browser is working - just auth isn't when I switch out www.bing.com for a corporate website needing authentication.

The error continues when testing with my corporate website that requires authentication.

Keep in mind in WPF this works flawlessly.

[pieths-ms]

@jeremiahjordanisaacson From the screenshot you shared above, it looks like you have only added the enterpriseAuthentication capability. Have you also tried adding the enterpriseCloudSSO capability. The enterpriseCloudSSO capability is the one that deals specifically with SSO and AAD sign-in.

Enterprise Cloud Single Sign On: The enterpriseCloudSSO capability allows apps to use single sign on with Azure Active Directory (AAD) resources inside a hosted web view control

[pieths-ms]

The enterpriseCloudSSO capability is in the rescap namespace:

  <Capabilities>
    <Capability Name="internetClient" />
    <uap:Capability Name="enterpriseAuthentication"/>
    <uap:Capability Name="sharedUserCertificates"/>

    <!-- Try adding this one -->
    <rescap:Capability Name="enterpriseCloudSSO" />
  </Capabilities>

Also requires adding the following to the list of available namespaces in the main "Package" tag:

xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"

Here is the <Package> tag from an older version of our UWP sample app with all namespaces included (note the addition of the uap and rescap namespaces):

<Package
  xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
  xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
  xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
  xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
  IgnorableNamespaces="uap mp rescap">

[jeremiahjordanisaacson]

@pieths-ms Eureka! It worked! Holy buckets that's a buried capability. Thank you so much for the help!

[pieths-ms]

@jeremiahjordanisaacson Awesome! Glad you got it working.

[sparkrod]

For anyone interested, our UWP app was just rejected for the MS store for including the restricted capability described here (enterpriseCloudSSO), after explaining the use case and referencing comments made here in github explaining that it is the only way to get it to work. The feedback given was this:
Engineers Comment: Your product needs to use broker for this scenario, either via MSAL or directly. We cannot approve the restricted capability to use SSO capabilities for privacy reasons.

In our case WebView2 is being redirected to resources protected by Microsoft Active Directory auth that uses Microsoft Entra Conditional Access policies requiring a device Id. We have no control over when our customers may be directed to use this kind of resource. Does their feedback make sense? How can we augment WebView2 to invoke some secondary process when it sees Microsoft authentication is required?

[jeremiahjordanisaacson]

For anyone interested, our UWP app was just rejected for the MS store for including the restricted capability described here (enterpriseCloudSSO), after explaining the use case and referencing comments made here in github explaining that it is the only way to get it to work. The feedback given was this: Engineers Comment: Your product needs to use broker for this scenario, either via MSAL or directly. We cannot approve the restricted capability to use SSO capabilities for privacy reasons.

In our case WebView2 is being redirected to resources protected by Microsoft Active Directory auth that uses Microsoft Entra Conditional Access policies requiring a device Id. We have no control over when our customers may be directed to use this kind of resource. Does their feedback make sense? How can we augment WebView2 to invoke some secondary process when it sees Microsoft authentication is required?

@pieths-ms This seems like it's going to be an ongoing concern for folks trying to release in the MS Store. @sparkrod Has a point.

[pieths-ms]

Hi @sparkrod , @jeremiahjordanisaacson . MSAL has dropped support for UWP. It looks like the WAM (Web Account Manager) APIs might be the best way forward.

When the app gets a token from WAM, it should be able to just use that token to access the site, whether the site requires conditional access or not.

The app has to find a proper way to use that token in WebView. For OAuth 2, the app would have to ensure that http header “Authorization: Bearer ” is set when WebView2 sends the http request. There are WebView2 API for the app to modify http request headers to achieve this.

Hope this helps guide you in the right direction. Please let me know if you have any questions. Thanks.

[sparkrod]

Hi @sparkrod , @jeremiahjordanisaacson . MSAL has dropped support for UWP. It looks like the WAM (Web Account Manager) APIs might be the best way forward.

When the app gets a token from WAM, it should be able to just use that token to access the site, whether the site requires conditional access or not.

The app has to find a proper way to use that token in WebView. For OAuth 2, the app would have to ensure that http header “Authorization: Bearer ” is set when WebView2 sends the http request. There are WebView2 API for the app to modify http request headers to achieve this.

Hope this helps guide you in the right direction. Please let me know if you have any questions. Thanks.

Thanks for following up! I will look into WAM, but I think that still leaves me with a couple of questions-
Is there a standard way to recognize the need for Microsoft Authentication while the user is navigating using Webview2? This would be the trigger for using WAM to obtain a token, I assume? Our app does not normally do Microsoft authentication, but users often use or app to access intranet resources or Internet resources protected by their Microsoft enterprise auth, and they wish to use conditional access policies to protect these resources.