As a a software and Web site user, I consider my desktop apps "mine" and Web sites "theirs." I am sure that this is the mindset of most people. We "visit" Web sites, and we "give" information to them. Yes, they do things for us in return. Even when providing SaaS, I am still on "their" site. On the other hand, when "I" use a desktop app, I am using "my" software on my computer and it is likely that "I" have other desktop apps to which I have given passwords and keys. In fact, "I" may even have "my" Browser remember passwords for Web sites I frequent as well as keep other personal information.
As a consequence of this distinction, while I consider OAuth a fine architecture in the context of Web workflow, it is (presently) not optimally suited for the desktop experience. As a user, I control my apps (well, presuming they are not malicious), and can turn them off or uninstall them at my discretion. A Web site is (very) different in that I have no real authority over it. btw: I think it is quite important to realize just how atypical/novel Twitter is in assessing the needs of a desktop solution: Twitter isn't really a Web site (though it has a Web site) -- Twitter is a messaging infrastructure, and client apps are end-points. In this regard, think of it more like email. The UX I want for users of my app is what I want when they use an email client: they'll use a Preferences/Wizard approach to add account (s), and thereafter the app provides functionality. Although users have the option of visiting Twitter's Web site to interact with Twitter, it is my goal (as I suspect it is for most clients), to over time obviate the need for users to go there. In this context, I see the needs for a desktop solution as: 1) don't ever send the user's password in the "clear" over an unencrypted transaction, even if obfuscated (e.g., Base64). 2) in spite of #1, don't require use of SSL/TLS for every transaction (that requires user authentication). 3) client apps should be uniquely identified, and Twitter should have the control to withdraw a client's access to Twitter's service. 4) empower a user to terminate an issued "token" (whether because the app turns out to be malicious, or because the token has been compromised). On Oct 12, 10:02 pm, JDG <[email protected]> wrote: > But it completely subverts the point of OAuth, because it lets a third party > have your password. Why even use OAuth in that case? > > > > On Mon, Oct 12, 2009 at 19:01, Zhami <[email protected]> wrote: > > > On Oct 12, 5:44 pm, Sebastian <[email protected]> wrote: > > > The solution for OAuth on Mobile and Desktop is easy: > > <snip> > > > Let me rewrite this in plain english: let the app ask for login/ > > > password and pass it to twitter. > > <snip> > > > All we need is a simple API call where we can trade a login and > > > password for an oauth access token, bypassing the browser. > > > I think this is a grand idea, and wanted to acknowledge it. > > > This solution removes the password from being bandied about endlessly > > with Basic Auth, but is appropriate for the world of desktop apps > > where users are comfortable providing their password because > > applications often ask for access restricted information. > > -- > Internets. Serious business.
