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

On Oct 12, 10:02 pm, JDG <> 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 <> wrote:
> > On Oct 12, 5:44 pm, Sebastian <> 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.

Reply via email to