

OAuth is a pain to use for desktop applications - ownedthx
http://www.ownedthx.com/blog/2009/05/10/oauth-is-a-pain-to-use-for-desktop-applications/

======
benburkert
I'm not sure the author understands the benefit of OAuth. here's an analogy:

First, let's assume that the end user uses the same username/password
combination for every website, which is quite common. Also, assume that
twitter and your server accept the username/password combination as a basic
auth encoded string. What you have, in OAuth terms, is a universally
acceptable auth token, without the shared secret (similar to an unsalted
password hash). Anyone in possession of this token can access any resource on
any website as the end user (assuming they have a single username/password
everywhere).

So OAuth allows you to take this universal token (or at least the information
contained in this token: username/pass), and generate a new access token which
can only access a limited resource for a given service, sometimes for a
limited period of time. Also, it has a shared secret, so it's harder to abuse.

For the end user, it's actually much safer to keep the access token & secret
locally vs. making them login to your central service with a
username/password. If the username/password gets out, they no longer control
their identity online. If the access token/secret gets out, they no longer
control the resource.

~~~
ownedthx
A good summary of OAuth, but as the author, I assure you I do understand this
key benefit of OAuth. Admittedly I didn't make a point of it, but there are
alot of sites that do a good job of explaining this (as well as your comment).

The issue of the article isn't that. It's when one is actually building a
desktop application from scratch. You end up building a web site with a user
login... just so you can store the application secret securely!

Note that when I say application secret, I'm not referring to the user's
access token & secret that you point out. I agree that storing that info
locally on the desktop is fine.

Thanks for replying.

~~~
weavejester
I'm not sure I understand why a desktop application needs to authenticate
itself with your server via a username and password in order to use OAuth.
Could you explain further?

~~~
ownedthx
If you can agree that there is no way to safeguard the application secret key
other than keeping it on a server (no matter how u try to bury it in the
desktop application, it could be hacked no?), then you have to let your
desktop application 'instances' use some sort of API to get their messages
signed.

But, you don't want to let anyone just come in and hit this API! That could be
expensive, in terms of CPU, bandwidth, and hosting costs. So you want to make
sure the desktop application is indeed authorized to do so. So then you need
some sort of authentication scheme between your desktop applications and your
server... username/passwords being a common such way.

~~~
weavejester
I'm afraid I still don't quite understand how a username and password is
required.

If it is free to sign up for a username and password, then people could just
sign up with your service and then hit your API directly. All you've added is
an inconvenient barrier for your users that wouldn't stop an attacker. After
all, if the attacker can be bothered figuring out how your application talks
to your server, he or she can probably be bothered signing up for a username
and password.

On the other hand, if your application costs money, then why not require a
valid license key to access your server. True, you'll get the problem of
people pirating software and reusing the license key, but it shouldn't be too
hard to monitor your server logs and ban any license key that is submitted by
a large number of unique IP addresses in a short period.

------
wooster
"You put it on a server, because it’s the only place you can ensure that it
stays safe."

Uh, what? If on OS X or iPhone, use Keychain. If on something else, do
whatever makes sense there. There's really no need to stick it on your server,
that I can see.

If the user loses it, you just generate a new one, right?

~~~
weaksauce
The author is not talking about the per user secret key. He is talking about a
secret API key that is used to encrypt all the communications from his
application. If you store that locally you run the risk of having anyone with
a decompiler be able to reverse engineer your specific API key.

~~~
wooster
Wow, okay. I hadn't dug into OAuth enough to get to that point. Is there any
reason the client token isn't authentication enough for the server to decide
to sign the request? If the app (client+server) has control of the
authentication flow, it shouldn't need another set of credentials to figure
that out.

------
seldo
This could be easily simplified to "OAuth is a pain to use". Bouncing the user
back and forth between consumer and publisher of the OAuth key is too long,
too complicated, and too confusing for use by the average consumer.

~~~
ownedthx
I tend to agree. I think some better documentation would do go a long way,
though.

------
psanford
What about open source apps. Do you force your users to register for their own
consumer key just to use your application?

