A common complaint amongst Twitter developers has been that Twitter’s OAuth, the authentication process you see when you click the Twitter login button on a 3rd party website and go to a Twitter-looking page with a “Allow” or “Deny” button, is too complicated. Mainly, from a user experience perspective, users are required to leave the 3rd party site completely in order to log into Twitter, then get redirected back to the 3rd party site again. If anything breaks along the way, the user is left wondering what to do, and valuable logins, purchases, or registrations could be lost. Facebook has solved this by enabling users to do all the login process via Javascript they provide that produces a popup. Users can log into Facebook without ever leaving the 3rd party site. It appears, based on a thread on the Twitter developers list, that Twitter is planning to one-up Facebook by allowing users to log in to 3rd party sites without ever even needing a popup or any type of redirect, and they’re already testing it with select partners.
The topic came up when other developers noticed that the site, TwitPic.com, was allowing direct Twitter logins right on their own website and somehow posts from TwitPic were showing up with the TwitPic name and link next to the post on Twitter. This normally isn’t possible without enabling OAuth login because Twitter has disabled the functionality for any non-OAuth produced Tweet. In fact they have said in June of 2010 they will be completely removing the ability to login through Twitter on 3rd party sites via plain-text authentication. So how is TwitPic doing it?
According to Raffi, an Engineer on the Twitter API platform team, Twitter is currently working on a new “OAuth Delegation” standard that will allow applications to allow users to log in via Twitter on their own sites, while still maintaining the control over Apps that OAuth gives providers and users. So, on TwitPic, for instance, you can log in to TwitPic.com with your own Twitter username and password right on the TwitPic site itself, yet you’ll still have full control on Twitter.com to revoke access to TwitPic at any time you want to. In addition, Twitter, at any time, can remove TwitPic’s ability to publish or access the Twitter API since they still have to use OAuth to make Twitter API calls.
If the hints in the developers list thread prove true, developers will be able to take the plaintext username and password, still store them somewhere, but in order to make calls through the Twitter API they’ll have to somehow send an OAuth key with their requests to Twitter along with some way of identifying the user. My guess is, in essence, the app will send a one-time login on behalf of the user to Twitter (most likely via a secure SSL encryption channel or similar), and Twitter will return to the app an OAuth token to make API requests with on behalf of that user in the future. In my opinion, this is still no different than storing an OAuth Token in a database that would give apps the same access as their Twitter username and password.
Security Concerns
While storage may be no different, I’m sure there will still be those concerned about this approach. For instance, what happens when users get used to entering their Twitter usernames and passwords on 3rd party websites and decide to do so on a malicious website? We’ve seen how used to entering Twitter credentials people get with websites that look like Twitter itself with the rampant phishing attacks recently.
Maybe Twitter is feeling comfortable enough that they can be proactive about such misuses and password collection. The risk is still there though and hopefully the OAuth Delegation Twitter is getting ready to launch will cover this problem.
Partners
Thus far, it seems TwitPic is one of the partners testing this new delegation standard Twitter is working on. Several others were mentioned in the developer discussions about this as well. For instance, Seesmic Look is also taking similar credentials without any OAuth redirect, yet still shows the “Look” source in Tweets generated with the app. One developer pointed out the information that could be retrieved from the new requests, and the security of it all is a little concerning.
Whatever it ends up being, the winners will be desktop and mobile client developers. Right now developing a mobile or desktop app involves deep integration into the browser in order to legally get the user logged into the app. It is why we see so few native desktop clients and so many AIR apps. AIR is a browser-based solution.
I’m very interested to see what happens. The Twitter team is supposed to announce more details very soon and I’d like to find out more about what this means for developers, how secure it is, and how much recoding I’ll have to do to enable it in my app. Whatever it is, you can bet it will be one step simpler than the currently more-simple solution which Facebook provides. This is getting very interesting! Let the API wars begin…
