Wrong, if the app went rogue the user could uninstall it, or just not
run it. And like I said in my other message, you don't need to follow
the rules if you are trying to be evil, so the whole argument against
allowing proxy applications to exist just because one could go rogue is
a moot point.
John Adams wrote:
On Mar 26, 2009, at 10:34 AM, atebits wrote:
I'm not saying OAuth is a panacea, but it is better than handing over
a password.
That's the crux of it. It's not a panacea (the UX sucks, especially
for iPhone apps), but the fact is it's only marginally better than
handing over a password. I mentioned this in my blog post (linked
above), but if I'm a native app, I can get your password if I want it
- OAuth or not. It's nothing more than the illusion of security in
this case.
It's not an illusion of security, it's a shift of control. In the
current system, the third party application has the user's credentials.
If the third party app goes rogue and performs malicious actions,
under OAuth, Twitter can revoke the application's rights wholesale, or
the user can revoke the application's rights to their account only.
To the twitter-folk: for implementation simplicity, I think you should
run with token-based authentication and deprecate Basic Auth. All I
ask in return is a "special" API method to exchange a username
+password for an access token. This way I can collect a username
+password client side (without directing the user to a webpage) and
authenticate.
Ah, but then your application would have the user's password.
The scheme you propose is a good intermediary step for a transition,
but not as a long term solution.
From the user's perspective, it's just as easy as OAuth.
Although much harder to revoke!
-j
---
John Adams
Twitter Operations
j...@twitter.com
http://twitter.com/netik
