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?
Thank you very much @aaronpk! Great answers, really appreciate it! 😊