Projectreunion: WebAuthenticationBroker.AuthenticateAsync throws COMException

[wbokkers]

Describe the bug
On WinUI 3 preview 3 for Desktop, when calling WebAuthenticationBroker.AuthenticateAsync, I get the following exception:
System.Runtime.InteropServices.COMException (0x800706BD): There are no remote procedure calls active on this thread. (0x800706BD) at WinRT.ExceptionHelpers.ThrowExceptionForHR(Int32 hr)
at ABI.Windows.Security.Authentication.Web.IWebAuthenticationBrokerStatics.global::Windows.Security.Authentication.Web.IWebAuthenticationBrokerStatics.AuthenticateAsync(WebAuthenticationOptions options, Uri requestUri, Uri callbackUri)
at Windows.Security.Authentication.Web.WebAuthenticationBroker.AuthenticateAsync(WebAuthenticationOptions options, Uri requestUri, Uri callbackUri)

This code previously worked in a UWP application without problems.

Steps to reproduce the bug

1. Call WebAuthenticationBroker.AuthenticateAsync

Example:
var result = await WebAuthenticationBroker.AuthenticateAsync(
WebAuthenticationOptions.None,
authorizeUri, redirectUri);

Expected behavior
I would expect the Microsoft authentication dialog to appear.

Version Info
NuGet package version:
[Microsoft.WinUI 3.0.0-preview3.201113.0]

Windows app type:
| UWP | Win32 |
| :--------------- | :--------------- |
| No (=works fine) |Yes (=exception) |

| Windows 10 version | Saw the problem? |
| :--------------------------------- | :-------------------- |
| May 2020 Update (19041) | Yes |

| Device form factor | Saw the problem? |
| :----------------- | :--------------- |
| Desktop |Yes |

[stevenbrix]

Adding some folks who may know if this API works in Win32 or not - @MikeHillberg @jonwis @oldnewthing

[BenJKuhn]

@wbokkers, thank you for bringing this to our attention. The best way you can help us is to file this in the feedback app. Once you've done that, please post the link here and I'll promote it to the right team for diagnosing & fixing. By filing in the feedback tool and collecting logs, you can help us better diagnose the issue.

Thanks,

Ben

[riverar]

@BenJKuhn When you suggest folks file bugs in Feedback Hub, please provide the category and sub-category, as the likelihood we get it right (and the right on-demand diagnostics get executed) is very low.

[BenJKuhn]

@riverar, can you file that feedback in feedback hub (jk!).

In this case it's not going to matter much. I'm going to promote it in our database and directly assign it to the right team as soon as I get a link to the feedback. I understand that it's not always easy to map some features to feedback hub categories.

In this case, "Developer platform" -> "API feedback" would be appropriate.

Ben

[riverar]

@BenJKuhn Fair.

If I remember correctly, that API still requires a CoreWindow.

Steps to reproduce

1. Install Windows 10 19042
2. Install Visual Studio 2019 Preview, with payloads indicated in the documentation (https://docs.microsoft.com/en-us/windows/apps/winui/winui3/#install-winui-3-preview-3)
3. Install WinUI 3 Preview 3 templates (https://aka.ms/winui3/preview3-download)
4. Launch Visual Studio 2019 Preview
5. Create a new app, using the WinUI 3 Preview 3 Blank App, Packaged (WinUI in Desktop) template
6. Change the inbox myButton_Click handler to be:
   csharp private async void myButton_Click(object sender, RoutedEventArgs e) { await WebAuthenticationBroker.AuthenticateAsync(WebAuthenticationOptions.None, new Uri("https://example.org"), new Uri("https://example.org")); }
7. Click Build > Build Solution
8. Deploy and run the solution
9. Observe reported error

Headscratcher corner

So taking a look at the "Developer platform" > "API Feedback" category/sub-category, I don't see any associated user-initiated feedback diagnostics. So that means there won't be any specific logs collected for this issue.

[riverar]

Filed feedback on behalf of @wbokkers to take advantage of @BenJKuhn's attention today
https://aka.ms/AAb2zbo

[jonwis]

If I remember correctly, that API still requires a CoreWindow.

Chatting with the team that owns WebAuthenticationBroker that's likely the concern. The "Broker" was necessary in a UWP so the user could enter their credentials into a Window displayed by the platform, rather than into one under the app's control. The Window was inferred from the thread calling RequestAsync (recall that a CoreWindow lives on a specific thread that it owns) so the broker knew where to show itself on screen and other attribution information.

We're discussing options for how to support people who were building UWPs with CoreWindow but are now investigating Project Reunion WinUI3 apps on Desktop Bridge. This category of problem - APIs that implicitly or explicitly need a CoreWindow - is high on our list to address (hi @AdamBraden !).

Question for the thread - would you want a 1:1 replacement of WebAuthenticationBroker in Project Reunion that launched the browser for authentication then redirected back to the app? Or would you just want a Really Good Sample of how to register a protocol for your Win32 app and then use it from your authentication experience?

[BenJKuhn]

For reference by OS team, the Windows work item number is 31649739. I left a back-pointer in the workitem to here as well.

@riverar, for what it's worth, even the general diagnostics provide a number of ETW data providers that can be helpful in debugging API failures. It's not as nice as having a scenario-tailored log, but it's not an empty data set either.

[riverar]

Question for the thread - would you want a 1:1 replacement of WebAuthenticationBroker in Project Reunion that launched the browser for authentication then redirected back to the app? Or would you just want a Really Good Sample of how to register a protocol for your Win32 app and then use it from your authentication experience?

I would prefer for Microsoft to continue owning that experience. Writing all that OAuth2 goop correctly can be tough and presents quite a hurdle for developers wishing to just access some token-required services. Having a single implementation would also maintain the consistency WebAuthenticationBroker sought to provide.

Might be useful to bounce ideas off the active Microsoft Authentication Library folks as well. (psst @mahoekst)

[BenJKuhn]

This is also a duplicate of issue #366. This is a known gap in platform support that is being looked at and tracked as an OS bug. A potential outcome of that might be that we consider addressing it as a new API in reunion. There are pro's and con's to both approaches. The specific crash in the specific API wouldn't be fixed as a Project Reunion bug though.

[riverar]

@BenJKuhn Given Reunion's goal of unifying access to existing Win32 and UWP APIs, it seems more appropriate to leave this (or the original) issue open, with a reference to the OS bug number, to track its progress.

Or perhaps this should be transferred to the Discussions area, as an Idea?

[BenJKuhn]

We've been carrying a lot of issues over to the OS repo. The developer engagement on this repo is great, though too. The challenge is that we don't want this to become a general Windows OS developer forum. Let's try it this way. The existing issues both focus on the inbox API. I've opened a separate feature request, cross-linked to these, that covers creating a new API, and spells out that it's distinct from updating the inbox functionality. We can track the inbox OS and Reunion asks separately, though we'd likely do one or the other. It's a subtle distinction, but worth separating for clarity.

https://github.com/microsoft/ProjectReunion/issues/441

[riverar]

@BenJKuhn Sounds fair, thanks! 👍