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.
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.
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.
"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?
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.
[+] [-] benburkert|17 years ago|reply
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|17 years ago|reply
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.
[+] [-] seldo|17 years ago|reply
[+] [-] ownedthx|17 years ago|reply
[+] [-] wooster|17 years ago|reply
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|17 years ago|reply
[+] [-] psanford|17 years ago|reply