Menu

I’ve finished researching the changes needed to integrate OAuth into Twitter Tools. The code changes are pretty straightforward and there is plenty of prior art and examples out there to reference. The technical implementation isn’t a problem.

My concern is with the user experience of the initial install and set-up of the plugin. This would take a pretty big hit if I implement OAuth according to my best understanding of the required guidelines. I’m exploring some other options to see if I can find a good way to reduce the required steps and keep a nice simple user experience.

Regardless, I still plan to have something ready for public release before the deadline – though time is getting a little tight.

This post is part of the project: Twitter Tools. View the project timeline for more context on this post.

The short of it is that you can either have users set up their own Twitter Applications (which is what I did), or you can relay authentication back through your own site (which makes everybody dependent on you keeping your site up).

I don’t mind using a Twitter app, since I’ve already set one up for API access anyway. I think that’s the best way to go about it if the other option is centralizing it. Creating the app is an easy enough process.

It’d be a real shame if this tool goes down upon the switch over to OAuth. it is the best WP Twitter integration solution.

From a non-technical user’s perspective, I’d shy away from forcing users of this plugin to have to go register their “own” twitter app just to use this. that is a much more intimidating barrier to entry than simply adding a few other steps after adding the plugin to WP.

seems sites like twitpic make it stupidly easy to authenticate with their giant “sign in with twitter” button. again, i have no real idea about how or why it is difficult to implement, just my two cents.

Duane – Each of your users should be registering their site as an application, not using your applications keys. I looked at your code and you are distributing your application’s keys in your plugin. From what I understand this is a big no-no.

We just updated WordTwit to work with OAuth. I’m not sure the process you implemented, but the end result we ended up with isn’t too bad. The user clicks a big “Authenticate with Twitter” button, which takes them to Twitter. If they are logged in, they simply click “Approve”, which redirects them back to the administration panel and they’re authenticated. There’s another method that uses a PIN and not a callback, which we did first, but I found it was a less than ideal user experience.

The WordTwit code is in the WordPress repository if you want to check it out. I expressed concerns as well to the Twitter API folks, mainly that there’s no way to protect the consumer secret in a PHP open-source application.

I asked that question on the Twitter API forum, and they agreed that having the consumer secret in plain text isn’t a great idea, but they also said there’s no real way around it. Did Twitter recommend every user creating their own application? That seems like overkill to me, although it’s probably the most secure scenario. What do the user’s call their apps? The application names have to be unique, I imagine lots of people might just give up after trying a few names if they hit conflicts.

This was the response from the Twitter developer when I asked the question about WordTwit (they mention obfuscation):

It really ends up just being a case of best-effort security. A desktop application makes its best effort to keep the secrets concealed, obfuscated, or stored.

The last thing you want is for those with malicious intent to masquerade as your application, giving it a bad name, and possibly getting it banned. You
want to make your best effort to make sure that doesn’t happen — especially if you have access to privileged features with more risk like xAuth — which
endangers not only your application but anyone who’s made the mistake of giving their login credentials to *any* third party. If I have a database of 500 Twitter logins and passwords, and I come across a key/secret combo with xAuth access, I can secure long-lived access tokens to act on their behalf — and your application will get all the infamy associated with that.

If abuse is detected, you can always regenerate your API keys and secrets and re-distribute your application.

Security is a cat and mouse game. Sometimes the cat devises clever mouse traps. But a clever mouse will always want to get its cheese. Storing credentials in plain text in an open source project or otherwise lets even the most lazy cats an opportunity to catch the mouse..

We recognize that there will never be absolute security in these things, and the best we can do is offer you the best possible tools to deal with abuse when it happens, and the best possible analytics to detect abuse. We aren’t all the way there yet, but we know what the score is.

@Duane: yeah, you don’t want to distribute your own keys in your plugin because that means any abuse that happens with those keys will be blamed on you â€” you should treat your app key and secret like any other username and password!

I agree, it’s technically possible, but I honestly don’t see it as very likely unless someone really has a hate on. It’s easy enough to create a dummy Twitter account and a dummy Twitter application on that account. Given that all the fields are supplied by the user, even the application creator, icon and hyperlink, it’s easy enough to spoof the application, so why go to the trouble of ripping apart someone’s code for the credentials? Plus, someone ultimately has to click Approve on the Twitter page. If the end user was at risk, I would be a lot more worried. But the only thing that can happen is someone can spoof the application. Do a lot of applications want to masquerade as a WordPress Twitter plugin? Maybe, but doesn’t seem like a big risk to me at this point.

Anyways, I’m definitely open to making changes, but I’ll wait until Twitter finishes that new method they are working on and leave it as is for now. I asked questions, even on the Twitter dev board, before doing the implementation, but nobody had any better ideas at the time. It seems more thought has been given into it since then

Duane – I think you’re missing the scenario that is most problematic – you have to think about the welfare of your users. Anyone who chooses to abuse your OAuth consumer keys will force Twitter to ban your app. Then every WordPress user that is using your plugin will lose their connection to Twitter until you update your plugin and they install the new version.

I agree it’s a problem, but I don’t believe asking every user to create a custom application on Twitter is the solution. The solution is the method that Twitter is working on for this scenario. As soon as they open that up I’ll make the changes in short order. Given that we’ll all probably have to make authentication changes again when Twitter releases that new method, I’d rather hold off having people do another interim authentication method to prevent a scenario that I think has a pretty low likelihood of happening. Hopefully Twitter will open it up this week and we can all make the necessary changes.

Reading @Duane’s comments of “I agree it’s a problem, but I don’t believe asking every user to create a custom application on Twitter is the solution” I think it’s rather ironic considering this: http://www.bravenewc[...]-know-about/