Unfortunately I don't think it is remotely possible to educate the general public enough about Oauth and why using a browser to authenticate is important. The RFC even recommends "in app browsers", which are not secure at all. I mean after all, TikTok was previously injecting JS into websites via their website to log keystrokes "for debugging purposes" (Ref: https://www.macrumors.com/2022/08/18/felix-krause-in-app-browser-javascript-tool/) People are trusting in general, and Oauth via a native app looks natural enough, that it is trivial to phish credentials in such a manner. In fact there are quite convincing Steam phishing attacks that seem to be prompting for Oauth, but they actually just generate a "browser window" in the fake website via pure CSS/JS. Anyway, I don't think an RFC can really solve it, since Oauth 2.0 is already everywhere. - Raghu Saxena ________________________________________ From: ietf <ietf-bounces@xxxxxxxx> on behalf of Michael Thomas <mike@xxxxxxxx> Sent: Wednesday, June 21, 2023 2:53 AM To: IETF Discussion Mailing List Subject: RFC 8252 is a complete joke About 10 years ago I discovered that IETF was working on OAUTH as a replacement for sites to need user credentials to do things on their users' behalf, typically for use to post stuff to social media sites at the time, but also as a convenient general login mechanism. I had a native app I wrote and I didn't like having to store use credentials so that seemed great. However when I thought about it it seemed there was nothing to prevent me to still get the login credentials from the user of my app. Native apps, like phone apps, have complete control of the UI unlike a web browser which can be assumed to be a neutral player from the user's standpoint. When an app asks you for your login credentials for, say, Facebook you have to make a decision whether you trust the app or not. With OAUTH it makes it seem like it's safe regardless whether you trust the app or not. It isn't. Since the app has complete control of the UI unlike a browser, it completely controls what the user sees. There is an infinite number of ways for a native app to game the user to get their credentials while still completing the OAUTH transaction on the user's behalf. I brought this up to the OAUTH wg at the time and was roundly flamed by the working group and especially the lead author at the time (who it seems flamed out later for seemingly unrelated reasons). The end result was a little line or two blurb in the security considerations and the end result is, as I predicted, that nobody would care about OAUTH use in native apps and it would become commonplace. Later I heard that the OAUTH wg had created RFC 8252 which at first I thought was vindication after the hostility I was shown by the wg. I was looking it up again today though and found out that instead of just being an information "don't do this" it is in fact a BCP. The jist is that native apps should use browsers to do the login. This is tantamount to asking foxes to be nice while guarding the hen house. Or closer to home, that RFC 3514 and the evil bit should be employed. Native apps intent on stealing your credentials can still steal your credentials no matter what RFC 8252 says and the user will be none the wiser. What should be the BCP is that OAUTH should *never* be used for native apps and that users should *always* be cognizant that an evil app can steal their credentials just like when I specifically had to store them for my app to do stuff on their behalf. How on earth did the IESG let this get through? I mean seriously, this is a complete joke. Asking people to not be evil is not security and is certainly not a best common practice. This RFC should either be declared historic or rewritten. Mike
