A good example of a desktop application using browser authentication is Github for Desktop.
They use custom URLs/callbacks for both OSX and Windows. Works very well. ——— Dominick On 25. February 2019 at 11:48:20, Vittorio Bertocci ( [email protected]) wrote: Ahh, as John knows this is a big pet peeve for me :) Although that's all true on mobile, on desktop things are more complicated. - Using a system browser on the desktop (Linux/Mac/Windows) means that you don't control the experience (there might be modal dialogs occluding the browser or any other Z order windows factors; the browser instance might have already other tabs open; the default browser of any particular machine can be different; users might need to take steps to get back to the app; etc) - Use of loopback adapters is banned by many big enterprises on their machines - The big security advantages of the approach on mobile, where apps are all nicely sandboxed, is not as pronounced in an environment where the user login session in the machine is the main security boundary (think keylogger attaching to the main windows events pump, or a debugger - all stuff not possible on mobile but viable on desktops) True, it would be fantastic if desktop OSes would offer system browser features comparable to what's available on iOS and Android - but today that doesn't appear to be the case. And the inability to leverage existing sessions when using embedded views on the desktop is a true pain. But judging from the behavior of the most popular desktop apps in market (Office, Slack, Adobe Reader, Visual Studio, even the Google Drive app for Mac...) losing the ability to access cookies is less of a nuisance for users than all of the above. And considering that desktop machines usually have their own way of identifying devices, that is also not much of a factor for desktop apps. The best practice has been discussed for the last 4 years and still all of the big apps above remain on embedded: it is however telling that the mobile apps from the same vendors all embraced the system browser approach. Since the native best practices came out, I have been working with desktop developers dealing with this cognitive dissonance of the best practice saying something that is very hard to put in practice. I understand that it is well intentioned and it is easier to give one single advice for both mobile and desktop, but while the necessary features and experiences are lacking on the desktop I am not sure how much of a difference it is making in that use case. On Mon, Feb 25, 2019 at 12:59 AM David Waite <[email protected]> wrote: > > > On Feb 24, 2019, at 10:43 AM, William Denniss <wdenniss= > [email protected]> wrote: > > > > For 1P sign-in, there are several good reasons to go with > ASWebAuthenticationSession, like syncing the signed-in session with Safari > and using it if it already exists. > > With enterprise 3P, you’ll have to use some web agent for authentication > pretty much no matter what, and you’ll almost certainly get pressure to use > ASWebAuthenticationSession, and/or potentially lose deals to competitors > during product evaluations. It is simply what is required for robust > integration into a corporate infrastructure. > > For 1P on iOS, it depends on the complexity of authentication for first > party. If you are just doing password and maybe SMS-based challenges, there > is decent enough native app integration for password sharing and SMS > keyboard for that to keep conversions high, even with having to > authenticate twice. > > However, if you want to authenticate the device (even pseudonymously with > session cookies) or do other factors, the authentication is simpler with > ASWebAuthenticationSession. Which means your life will be easier if you > have more complex authentication requirements anywhere on your roadmap to > just start off using ASWebAuthenticationSession. > > It is likely that future authentication technologies like WebAuthn will > not work with an embedded web view. The ability to arbitrarily inject > javascript means that apps can phish webauthn responses for domains via > embedded web views. > > -DW > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
