Comments on: OAuth Alternative for Twitter http://blog.docuverse.com/2009/01/05/oauth-alternative-for-twitter/ Don Park's Personal Blog Fri, 11 Jun 2010 22:18:11 +0000 hourly 1 http://wordpress.com/ By: Tim Gets Your Apps Talking Securely at Acts As Conference 2009 http://blog.docuverse.com/2009/01/05/oauth-alternative-for-twitter/#comment-469 Tim Gets Your Apps Talking Securely at Acts As Conference 2009 Wed, 14 Jan 2009 14:00:34 +0000 http://donpark.wordpress.com/?p=73#comment-469 [...] to allow application access rather than usernames and passwords. Bloggers including Louis Gray and Don Park have suggested that Twitter implement OAuth, and there’s been more discussions on Chris [...] [...] to allow application access rather than usernames and passwords. Bloggers including Louis Gray and Don Park have suggested that Twitter implement OAuth, and there’s been more discussions on Chris [...]

]]> By: Don Park http://blog.docuverse.com/2009/01/05/oauth-alternative-for-twitter/#comment-464 Don Park Tue, 06 Jan 2009 14:12:11 +0000 http://donpark.wordpress.com/?p=73#comment-464 Hey, Blaine. What are you cooking at Yahoo? ;-p Sure, PAuth is less secure than OAuth. But, heck, it's just as secure as Twitter website login. Like I said, it's a biz decision in the end. Agreed on conversation greasing the path toward goodness for everyone. Hey, Blaine. What are you cooking at Yahoo? ;-p

Sure, PAuth is less secure than OAuth. But, heck, it’s just as secure as Twitter website login. Like I said, it’s a biz decision in the end.

Agreed on conversation greasing the path toward goodness for everyone.

]]> By: Blaine Cook http://blog.docuverse.com/2009/01/05/oauth-alternative-for-twitter/#comment-463 Blaine Cook Tue, 06 Jan 2009 11:14:56 +0000 http://donpark.wordpress.com/?p=73#comment-463 Implementing OAuth for Twitter isn't a big deal - it's the documentation, rollout, and communication with users that's the trouble. Likewise, client developers won't have much difficulty adapting their stuff to work with OAuth, since it's a simple workflow change and the addition of a wrapper around the HTTP requests they're making. PAuth is certainly simpler for client developers, but would require more of the "hard" documentation / communication work from Twitter. How do you explain to users that they should get new passwords for all their existing apps, particularly when you have no way of identifying said applications? What does the UI look like for that, and have existing apps been built to adequately deal with password changes? Once all that's said and done, PAuth is less secure than OAuth - I can still steal your password from an open wifi cafe every time Twitteriffic makes a request. :-/ I think what's needed overall is more and better documentation of secure protocols. This conversation and others like it is helping to further awareness about the reasons, options, and pitfalls for and of security on the web, which is good for everyone. Implementing OAuth for Twitter isn’t a big deal – it’s the documentation, rollout, and communication with users that’s the trouble. Likewise, client developers won’t have much difficulty adapting their stuff to work with OAuth, since it’s a simple workflow change and the addition of a wrapper around the HTTP requests they’re making.

PAuth is certainly simpler for client developers, but would require more of the “hard” documentation / communication work from Twitter. How do you explain to users that they should get new passwords for all their existing apps, particularly when you have no way of identifying said applications? What does the UI look like for that, and have existing apps been built to adequately deal with password changes?

Once all that’s said and done, PAuth is less secure than OAuth – I can still steal your password from an open wifi cafe every time Twitteriffic makes a request. :-/

I think what’s needed overall is more and better documentation of secure protocols. This conversation and others like it is helping to further awareness about the reasons, options, and pitfalls for and of security on the web, which is good for everyone.

]]> By: donpark http://blog.docuverse.com/2009/01/05/oauth-alternative-for-twitter/#comment-462 donpark Tue, 06 Jan 2009 05:58:25 +0000 http://donpark.wordpress.com/?p=73#comment-462 True. I am writing new Twitter client code (again) now so I definitely could use it but that's not the case for all the code and services built around Twitter already. It's a business decision I think although I don't see any problem with doing both. PAuth w/o fine-grained permission should be doable in a week. True. I am writing new Twitter client code (again) now so I definitely could use it but that’s not the case for all the code and services built around Twitter already. It’s a business decision I think although I don’t see any problem with doing both. PAuth w/o fine-grained permission should be doable in a week.

]]> By: Kevin Marks http://blog.docuverse.com/2009/01/05/oauth-alternative-for-twitter/#comment-461 Kevin Marks Tue, 06 Jan 2009 05:51:14 +0000 http://donpark.wordpress.com/?p=73#comment-461 Well, we shipped OAuth for all Google APIs so they can change. If Twitter hadn't put OAuth on the backburner 9 months ago they would be further along with it. Well, we shipped OAuth for all Google APIs so they can change. If Twitter hadn’t put OAuth on the backburner 9 months ago they would be further along with it.

]]> By: donpark http://blog.docuverse.com/2009/01/05/oauth-alternative-for-twitter/#comment-460 donpark Tue, 06 Jan 2009 05:26:35 +0000 http://donpark.wordpress.com/?p=73#comment-460 Hi Kevin. Long time no see. I expect lazy users to continue to use primary password, paranoid users to use limited passwords all the time, and most users to choose depending on perceived security of the consumer site/client where choices are: primary, limited, or don't use. I just don't think OAuth is appropriate when there is a huge body of third-party software and services that need to change. Hi Kevin. Long time no see. I expect lazy users to continue to use primary password, paranoid users to use limited passwords all the time, and most users to choose depending on perceived security of the consumer site/client where choices are: primary, limited, or don’t use.

I just don’t think OAuth is appropriate when there is a huge body of third-party software and services that need to change.

]]> By: Kevin Marks http://blog.docuverse.com/2009/01/05/oauth-alternative-for-twitter/#comment-459 Kevin Marks Tue, 06 Jan 2009 05:18:13 +0000 http://donpark.wordpress.com/?p=73#comment-459 Yet another 'Authentication without Authorization' idea. Or rather a 'get the user to do the auth management protocol'. Users already use the same password for multiple sites - what makes you think they'll bother to manually bounce back and forth to twitter to create a per-domain token rather than let OAuth do the exchange for them, with all that signing and shiny cryptography. Yet another ‘Authentication without Authorization’ idea. Or rather a ‘get the user to do the auth management protocol’. Users already use the same password for multiple sites – what makes you think they’ll bother to manually bounce back and forth to twitter to create a per-domain token rather than let OAuth do the exchange for them, with all that signing and shiny cryptography.

]]>