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…
I share your concerns about storing Twitter user credentials on third party sites. Phishing is not solved that way. While Twitter can deny the third party access to its service, users' passwords could already be sold, used,… Certainly not a good idea.
[…] we’re starting to see news around Twitter and OAuth Delegation. Add it all up and what do you get? The power lies in the API. […]
[…] here to read the rest: Twitter Testing “OAuth Delegation” With Select Partners – Genius … Share and […]
is it clear to the user that they are logging into twitter in a delegated way (as opposed to simply giving your twitter password to the third-party publisher/app)?
Sounds like http://friendfeed.com/api/documentation#install…. Google does something similar: http://code.google.com/apis/accounts/docs/AuthF…. So does Foursquare: http://groups.google.com/group/foursquare-api/w….
This is a horrible idea, but I guess *somebody* wants it. I still think that any site asking for my username and password from another site is broken if OAuth, or something like it, is available.
I'm not sure about that. I hope they can make that clear – there is a huge phishing concern with this.
Ah – interesting. Thanks for sharing that, Ben! I didn't realize FriendFeed did that. What are you doing to ensure web apps aren't using it, or that there is no phishing concern? I'm just curious if that's just a developer responsibility or if there is some level of protection against the potential possibility of phishing on sites that collect usernames/passwords.
Rahsheen, it's relatively safe for you, the user, so long as it's a site you can trust that you're giving your Twitter credentials. Right now these sites that are using OAuth are already storing credentials on your behalf that they can make calls on your behalf to the Twitter API without your permission. The only difference is it's not your Twitter username and password – it has the same potential though.
JessieStay, the author of this article is also CEO of the excellent SocialToo.com – a site that provides tools for facebook and twitter users.
While I haven't yet met Jessie in real life, in my experience on twitter and at socialtoo, he is prompt, very helpful and a great guy!
Jessie has helped me build a following of over 75,000 people at https://twitter.com/DrJeffersnBoggs where You and everyone are followed back.
We do a few things to prevent issues:
1) Changing your password automatically revokes any tokens made through that process
2) When using that token your limits are keyed by the IP address. So it can't be used to easily get a bunch of tokens and get around rate limits.
Other than that it's mostly developer responsibility. I trust you guys 🙂
And that's what I love about FriendFeed 🙂 Now if can get a better vision
on what you're going to do with it I can start developing for it again 😉
Loyal user to the end…
Thanks Jefferson – can't say it was me that helped with that, but hopefully
SocialToo's tools have been helpful!
I don't know – we haven't seen the details of this yet. You could probably
try Twitpic or Seesmic Look and find out there. Even there we don't know if
those are baked solutions yet.
This is frustration since we have just had our twitter account hacked and seem to not be able to log in and change our password let alone tweet. We have not been able to reach anyone at Twitter and none of the suggestions on their site are helping. Since we have spent a long time building reputations and tweeting this is a great lose to us. I am not sure how to fix this so adding more features like this already is making me nervous.
Dale, have you tried opening a ticket at http://help.twitter.com? I've
found they're pretty responsive. All I can say is be careful who you trust
with your Twitter username and password. That should always be the case.
Only difference? But that is a BIG difference IMO!
With a twitter username and password you can even change the original password. And there is no way to get back to a safer state once the password is out.
With OAuth you can revoke the oauth token anytime.
[…] we’re starting to see news around Twitter and OAuth Delegation. Add it all up and what do you get? The power lies in the API. […]
[…] something here? Twitter is working with select partners to test what is variously being called OAuth delegation or browserless OAuth credentials exchange method (not sure why browserless since it’s not […]
Interesting article!
TvvitterBug 1.4 Just released on the App Store is fully compliant with both OAuth and xAuth (browser-less authentication). Browser-less authentication allows mobile clients to bypass the pop-up authorization page altogether by providing the user's credentials securely to Twitter on behalf of the user. The added side benefit is that it helps eliminate phishing threats by always communicating to Twitter directly over a secure channel. It also helps protect the user experience of the app by eliminating the distraction of manually authorizing the app. Authentication is performed entirely in the background with no user involvement required. In fact, the user is oblivious to the authentication transactions being performed on their behalf.
TvvitterBug is one of the “new breed” of Twitter clients for the iPhone, iPod, and iPad that brings a fresh approach to mobile Twittering that focuses more on achieving the highest quality “user experience” (UX) possible, as opposed to simple “feature stuffing”.
You can look it up on the web at: http://www.tvvitterbug.com or on Twitter.com/TvvitterBug.
Hi Jesse, thanks for your reply. Sorry for the late response. What I have found out is that my email provider had such tight security that my email from twitter was not getting through to me. So when I reset the password or reach out to twitter, I never got a response. This has been cleaned up and we now offer email for our clients so that we can manage our own email accounts and some for our clients. It was easier to mange our own destiny than leave it in the hands of others.
Hi Jesse, thanks for your reply. Sorry for the late response. What I have found out is that my email provider had such tight security that my email from twitter was not getting through to me. So when I reset the password or reach out to twitter, I never got a response. This has been cleaned up and we now offer email for our clients so that we can manage our own email accounts and some for our clients. It was easier to mange our own destiny than leave it in the hands of others.
Interesting article!
TvvitterBug 1.4 Just released on the App Store is fully compliant with both OAuth and xAuth (browser-less authentication). Browser-less authentication allows mobile clients to bypass the pop-up authorization page altogether by providing the user's credentials securely to Twitter on behalf of the user. The added side benefit is that it helps eliminate phishing threats by always communicating to Twitter directly over a secure channel. It also helps protect the user experience of the app by eliminating the distraction of manually authorizing the app. Authentication is performed entirely in the background with no user involvement required. In fact, the user is oblivious to the authentication transactions being performed on their behalf.
TvvitterBug is one of the “new breed” of Twitter clients for the iPhone, iPod, and iPad that brings a fresh approach to mobile Twittering that focuses more on achieving the highest quality “user experience” (UX) possible, as opposed to simple “feature stuffing”.
You can look it up on the web at: http://www.tvvitterbug.com or on Twitter.com/TvvitterBug.
[…] we’re starting to see news around Twitter and OAuth Delegation. Add it all up and what do you get? The power lies in the API. […]
Only difference? But that is a BIG difference IMO!
With a twitter username and password you can even change the original password. And there is no way to get back to a safer state once the password is out.
With OAuth you can revoke the oauth token anytime.
I don't know – we haven't seen the details of this yet. You could probably
try Twitpic or Seesmic Look and find out there. Even there we don't know if
those are baked solutions yet.
JessieStay, the author of this article is also CEO of the excellent SocialToo.com – a site that provides tools for facebook and twitter users.
While I haven't yet met Jessie in real life, in my experience on twitter and at socialtoo, he is prompt, very helpful and a great guy!
Jessie has helped me build a following of over 75,000 people at https://twitter.com/DrJeffersnBoggs where You and everyone are followed back.
Ah – interesting. Thanks for sharing that, Ben! I didn't realize FriendFeed did that. What are you doing to ensure web apps aren't using it, or that there is no phishing concern? I'm just curious if that's just a developer responsibility or if there is some level of protection against the potential possibility of phishing on sites that collect usernames/passwords.