-
Notifications
You must be signed in to change notification settings - Fork 317
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebAuthenticationBroker API that supports all WinAppSDK OS's and application types #441
Comments
And, of course, this should build on top of WebView2! Note. The UWP one is based on IE and because of this will not work with many websites, forcing the developer to not be able to use WAB for Oauth with those sites. |
This was originally a request on the WebView2 team here: MicrosoftEdge/WebView2Feedback#171 There's probably some interop involved I believe between Edge, the OS, and WebView2? |
I disagree. I'd rather we use the user's default browser to log in, then use protocol activation to come back to the application, as it follows better practices, and is impossible to spoof, and also has the benefit of supporting any saved credentials the user might have in their browser. I managed to actually make this work, but it was a lot of work, lots of code, manifest changes for protocol activation, dealing with app activation args, finding the right instance, shutting down the app if it was the wrong instance, redirecting to the correct instance, then dealing with resuming the authentication workflow there. It was quite non-trivial, and I really wish this could be wayyyyyyyyyyy easier. Another reason to not require webview2: There's no guarantee webview2 is actually available to the user. |
I agree with everything you've got here - it's important to use the same browser as the user is used to because it may have SSO cookies already set up making the auth basically no-op, or the user might have a password manager associated with it (Edge, LastPass, etc.) where they store their cookies. For reference, there is https://github.com/Microsoft/cpprestsdk/blob/master/Release/src/http/oauth/oauth2.cpp (and its friend https://github.com/Microsoft/cpprestsdk/blob/master/Release/include/cpprest/oauth2.h), which we'd have to review to see if it behaves correctly. VSCode already does this as well, setting itself up a temporary HTTP server to support the redirect, etc. |
Clever trick with the temporary http server. Very clever actually. There are some challenges though with available ports, and what ports you get to configure in the oauth redirect configuration |
If you need a reference implementation, please feel free to use MSAL's, it is MIT licensed. WebView2 The discussion around embedded vs system browser is long and inconclusive. When it comes to Azure Active Directory, we've concluded that on desktop it's better to use a broker (WAM on Windows) because brokers increase security and SSO. Internally the broker uses an embedded browser. Many apps use browsers today and generally the embedded browser are preferred because they provide a better user experience. System browsers are cross-plat but the experience is worse. I have not yet seen any conclusive evidence that system browser is better or worse than embedded browser in terms of security. In terms of SSO, embedded browsers fare poorer, because you are likely to have SSO cookies in your system browser already. But once you start using the embedded browser, it should store the cookies as well. Hope this helps. |
Until the WinAppSDK adds this, I've added this ability to WinUIEx v1.4. It's nothing more than a simple one-line call. See https://dotmorten.github.io/WinUIEx/concepts/WebAuthenticator.html |
The solution by @dotMorten works well if you are controlling the app, but not so much as a library - and especially as maui which is a framework that libraries will be based on. The issue is that the auth callback starts a new process - which may be unexpected for the app, and then it also modifies app state unexpectedly (that may override user data or be overridden by user data): https://github.com/dotMorten/WinUIEx/blob/main/src/WinUIEx/WebAuthenticator.cs#L108 The killing of the new process may also be unexpected for the app: Not sure what the best solution is, but having this in a popup that is controlled by wasdk is more contained and does not require any new processes. This pop out to a browser works on Android/iOS because even though a "new window" happens, it is the same process and can be intercepted in known places. iOS has a special place, and Android can have a special activity designed for handling callbacks. Windows on the other hand launches a brand new app. I appreciate that popping out to the browser is a "better" scenario from the user's credential perspective and default browser, but this is not super windows-friendly. The callback triggers a new proc, which is killed and even if there was a way to share data, Windows doesn't have a place to decide where a new app should be launched or not. |
Note: This only happens if the user didn't already set that state. Personally I'd like to see something that's a combo of a popup and using the default browser - ie some way a browser knows the request is coming from a specific app and knows to direct you back to that specific app instance and close that tab gain, instead of asking the user to open the app again from the browser - ie overall more akin to what iOS and Android does. |
Any movement or guidance on starting new Maui/WebAPI/BlazorServer combined solution? Is a solution soon? I am following this Microsoft tutorial but says Windows not working yet. |
Will there be a way to leverage the ASP. NET CORE API server as the backend server? All of my various clients, including Blazor Server, already go through the API for DB access. If yes, any chance someone could make a tutorial for this solution setup? Our goal is 100% of business logic and per-method authorization is contained in the API so our customers could build their own clients if they choose as we are a SaaS provider. |
Has anybody found a workaround for use in MAUI windows apps? I would appreciate if you can share any insight on this! Really frustrating! |
@FedericoSMEC can you post your code for a workaround, please? |
Any update? |
@elijahmontenegro Yes: https://dotmorten.github.io/WinUIEx/concepts/Maui.html#use-winuiexs-webauthenticator-instead-of-net-mauis |
Hi @dotMorten , I tried to reference WinUIEx.WebAuthenticator in the App.xaml.cs but I don't see CheckOAuthRedirectionActivation() method on there. I am using the 1.5 version of WinUIEx package. Am I missing something? |
@ataparia Let's do this over at https://github.com/dotMorten/WinUIEx/discussions |
Looks like not only Google, but Facebook has also banned the use of embedded browsers and asking developers to use platform-provided authentication APIs on Android: https://developers.facebook.com/blog/post/2021/06/28/deprecating-support-fb-login-authentication-android-embedded-browsers/ |
I'm also having this issue. The workaround suggested might be an option, but please fix! Issues like this makes developers run away from .NET MAUI. :( |
I have tried the workarounds from Both seem to do about the same thing. It does fire up a browser with the login page, however, the created url-parametes gives me 403/forbidden on our auth service. |
@Brosten please, anyone having WinUIEx issues, post them in my WinUIEx repo - let's keep this thread focused on the real issue. |
This issue is over 2.5 years old. Is there any reason why the assignee @ujjwalchadha has not commented on this? |
Do we know if anyone on the MAUI team is monitoring this issue? This is a critical block for migrating to MAUI. Between this issue and the inability to publish MAUI UWP apps that reference a MAUI class library (dotnet/maui#8304), it feels that UWP support for MAUI is being de-prioritized. Wondering if I should drop the platform and only support Android and iOS. |
Last thing we were told (during community standup I believe), was that it isn't planned for v1.5. |
Can we get some attention on this issue? The problem has existed for quite some time now and prevents simple things such as authentication from working in MAUI for Windows. And I can't imagine MAUI is the only one that uses this. It's unbelievable how Microsoft is trying to push for a new standard for cross-platform application development but can't manage to make their own OS work with it. |
Is there any other way to implement social logins in MAUI besides using web authenticator? I tried it today and on windows it throws an exception without an actual exception message. I only want to develop desktop app for windows and mac, no mobile needed and I'm scrathing my head over this.
|
Are you able to implement a protocol handler or run a web server on a port, and do your login via the user's browser? This seems to be the way some apps handle the login problem. Login in App -> Start web server [optional] -> Open browser to login - > User logs in via browser -> callback url is either https://localhost:10234/login_callback or myawesomeapp://login_callback which gets the token back to you and completes the process. |
Thank you @dotMorten But the question is, if there is a solution why Microsoft can't build it into WebAuthenticator. |
@solomonfried Preaching to the choir. I've done my fair share of pushing for this, all the way to the point where I had meetings with the team that promised would look into doing this and explaining the reasonings why it is important, but I haven't seen any progress yet. I'm just as puzzled as you, but they are well aware of the limitation at this point, but I don't know what is keeping the priority of this back - I can't really make sense of it. On the other hand I have no clue why .NET MAUI has left the old UWP implementation in place for MAUI when it doesn't work outside UWP, rather than just deleting all that code and throwing a more helpful PlatformNotSupported exception. Perhaps @PureWeen can answer that. I created a PR to at least remove the code from MAUI and throw a more helpful error that directs you here. |
@ThreeSevenths Thank you for the info. That seems to be the way of doing it on the desktop apps, which was my main question as to why is web authenticator used (I'm new to desktop development). @dotMorten And of course, big thank you for your amazin library and fix for web authenticator! I tried it and it works as expected. |
@BenJKuhn @codendone this is a crucial API. whats the latest update on this? |
Proposal: Lifted WebAuthenticationBroker API that supports all Reunion OS's and application types
See #398, #366 - This issue is similar, but distinct in that it covers creating a new, lifted API, rather than updating the existing one to work for more application types.
Summary
Create an API that developers can use in any application type to implement OAuth2 functionality in any app supported by Reunion.
Rationale
The existing OS API that provides this functionality requires a core Window, which, for practical purposes, means that it only works for UWP-style application, and can't be used in other types of applications. Even if the OS API were updated, it would likely only be updated for new OS versions. It would be helpful for developers to have consistent support across OS versions.
https://task.ms/31649739
The text was updated successfully, but these errors were encountered: