Some questions about OAuth 2.0 for native (desktop) apps

oauth2-desktop-apps.md

Some questions I took an opportunity to ask in this Twitter thread:

• How bad would it be to include a very short-lived OTP in a custom protocol URL link inside a web page, which takes user from their default browser to a locally installed native desktop app (say, Electron or WPF based)? So they don't have to authenticate again within the native app. More context here.

• Most native desktop apps (e.g., MS Teams) don't seem to follow RFC8252 that requires to use external user-agents (i.e. default browsers) for authorization flow. Instead, they "cheat" and use their own internal WebView to host the external OAuth providers web UI. What's the reason behind this choice? Is this only because it's allegedly considered user-unfriendly to lauch the default browser? Should the industry come up with some solution to enforce the recommended behavior and perhaps make it more user-friendly?

• I respect all the extra measures (like PKCE) to protect the interception of the authorization code for the native apps scenarios. That said, I've recently fresh-installed Opera and suddenly I could go into my Gmail account without having to login in an Opera window. Because Opera had just quietly imported all my long-lived access tokens from Chrome. It's a true story. There was an in-thread response that the Desktop is inherently untrusted and thus I should just carefully mind what I install. Which is also true, but in this light, wouldn't PKCE and other precautions to improve the security of the OAuth 2.0 flow for native apps look a bit like over-engineering?

How bad would it be to include a very short-lived OTP in a custom protocol URL link inside a web page, which takes user from their default browser to a locally installed native desktop app (say, Electron or WPF based)? So they don't have to authenticate again within the native app. More context here.

Coming up with custom mechanisms for this kind of stuff is generally dangerous and you're on your own in terms of determining whether it's secure and where the attack vectors are. Sticking with OAuth + OpenID Connect means you have a lot more eyes on those protocols, and even entire multi-day events dedicated to people improving the security.

If your goal is to have someone who's already logged in in a browser get logged in in the native app, that's exactly what OAuth can help you with by the app doing an OAuth flow where the app launches the browser to the web server and they'd already have a session there so they wouldn't need to type in their password.

Most native desktop apps (e.g., MS Teams) don't seem to follow RFC8252...

This is unfortunate, but I have seen this a lot as well. It's definitely not safe, and is super vulnerable to phishing, which we're seeing being taken advantage of much more often lately.

Should the industry come up with some solution to enforce the recommended behavior and perhaps make it more user-friendly?

Yes, this is called OAuth 2.0 for Native Apps 😄

Because Opera had just quietly imported all my long-lived access tokens from Chrome

Yes, this is a problem with the desktop environment of apps having access to the entire filesystem, as well as a problem with bearer tokens that are not sender-constrained.

This does not however mean that PKCE isn't useful, because PKCE is protecting a completely different step in the flow. PKCE is all about protecting the authorization code while it's in transit through an untrusted channel.

Thank you very much @aaronpk! Great answers, really appreciate it! 😊