OAuth Alternative for Twitter
The obvious solution (pun intended) to Twitter auth problem is OAuth. As Biz wrote, OAuth won’t prevent hacking but should reverse increasingly common practice of third-party software and services asking for Twitter credentials. However, OAuth is a disruptive change, one that will break existing code and force everyone to change over. In this post, I will propose a practical alternative to OAuth that offers smoother transition.
PAuth
The core idea behind PAuth is to continue using password for auth but allow multiple passwords to exist for an account, each potentially bound to specific set of clients and permissions.
The key advantage PAuth offers to fast moving services like Twitter is that no client software change is necessary.
User Experience
- User wants to use Twhirl but, to enable it, Twitter username and password is necessary.
- User signs into Twitter with primary password and proceeds to creates generate a limited password for Twhirl, enabling only the permissions Twhirl needs.
- User uses the limited password to enable Twhirl.
- When user stops using Twhirl, limited password for Twhirl is deleted.
Multiple Posters
An interesting use of PAuth is limiting password to post-only. By issuing each poster a post-only password, multiple users will be able to post to a single Twitter account and admin (primary password holder) will be able to ban individual posters at any time without affecting other posters.
Details
Limited passwords should be generated for convenience and security. Since limited passwords are maintained by the PAuth provider and typically copy/pasted over to consumer site/client, it can be longer than usual passwords also.
Kevin Marks 9:18 pm on January 5, 2009 Permalink
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.
donpark 9:26 pm on January 5, 2009 Permalink
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.
Kevin Marks 9:51 pm on January 5, 2009 Permalink
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.
donpark 9:58 pm on January 5, 2009 Permalink
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.
Blaine Cook 3:14 am on January 6, 2009 Permalink
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.
Don Park 6:12 am on January 6, 2009 Permalink
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.
Tim Gets Your Apps Talking Securely at Acts As Conference 2009 6:00 am on January 14, 2009 Permalink
[...] 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 [...]