Add OAuth WebAuthenticator support to Windows

[dotMorten]

Description of Change

Adds OAuth code generation support to WebAuthenticator on Windows.
Note: Windows only supports Code generation, but sample app uses the less secure Token requests, which isn't really what you should be using in apps.
If this is a major concern/limitation, we have a few options:

1. provide feedback to the WinAppSDK team that they need to re-enable support for non-code requests (this was there in the early designs). FYI @akanpatel2206
2. Build this ourselves. There's nothing in the WinAppSDK itself that really is needed at this point to build the same experience - This is what WinUIEx already does. I'll be happy to lift that code into here (however one concern there is that the WinUIApplication class needs to be able to call into the WebAuthenticator class which is in the Essentials library to complete the authentication and that isn't currently possible)

The problem with 1 is that if the user doesn't make a code-based authentication, the redirect check will fail and a new app instance will get launched instead, rather than just complete the token request, or at least provide an error to the user to switch to using code. I didn't find a way to perform a runtime check here, since there's no guarantee that the request url contains that parameter (the test sample app here actually relies on the service to add that in its redirect so the app never sees the full request url).

Issues Fixed

Fixes # #2702

[dotMorten]

Actually the larger issue appears that the test service isn't preserving the State parameter during the round-trip: https://xamarin-essentials-auth-sample.azurewebsites.net/redirect?access_token=testtokenvalue&refresh_token=testrefreshvalue&expires=99
That's a key requirement for oauth and for the Windows App SDK, and prevents the tests from passing.

[IlGalvo]

Correct me if I'm wrong, but right now this method only works for packaged winapps, right?

[dotMorten]

@IlGalvo I’ll correct you. It’ll work for unpackaged too 😆. There’s even a nice helpful error in my PR if you don’t configure your app right for it

[IlGalvo]

You are absolutely right.

I was thinking, though: wouldn't it be better if you used ActivationRegistrationManager.RegisterForProtocol and ActivationRegistrationManager.UnregisterForProtocolActivation programmatically in a try-finally statement?

So as to reduce the developer's load.
Also because, if declared, the parameters are available in appxmanifest xml.

[dotMorten]

@IlGalvo I had considered it, but a little uncomfortable with making such app-wide registrations for unpackaged apps, since there's no guaranteed way to remove that registration on app-uninstall (since there's nothing to uninstall), and if the user never completed the auth workflow, it'll be left behind. Especially because the current WebAuthenticator APIs in MAUI does not allow for passing a cancellation token, you can't actually cancel the request and move on, so there's no where to clean up the registration - however the user-code could totally have the cancel/abort waiting for the authentication to complete, and in their code would have the perfect place to remove the registration.
That is also the approach I used in WinUIEx: https://dotmorten.github.io/WinUIEx/concepts/WebAuthenticator.html#unpackaged-apps

[IlGalvo]

That's actually a valid point.

But the problem/doubt I have for a maui app is that it will always be the developer's responsibility to implement windows platform specific code in case the flow is not completed or the app is killed.

This involves cluttering up the code quite a bit in my opinion and in a cross-platform context I would consider trying to handle this somehow within the framework.

Every developer should implement more or less this code (maui app that supports webauth in win pack/unpack):

I think it should be avoided, what do you think?
We could manage to find a better way.

[dotMorten]

I agree this isn't great, but you could just register it up front on app start up once and for all, or on app installation. Honestly I don't think it is a great idea to do these sort of things with unpackaged apps in-code, but really should be done as part of the installer, so the uninstaller can clean up as well. This is one of the reasons apps with an identity is such a great idea (I was sad/annoyed to see MAUI removed package app as the default setting in new projects, causing more of these issues, whereas the ios/android/catalyst apps are always packaged and don't suffer from these issues)

[IlGalvo]

I know, you are absolutely right in fact.
But unfortunately, I have seen that companies often prefer unpackaged apps because of the ease of automatic deployments.

So you suggest something like that?

In case I think it should be properly documented.