I didn’t post many details in my previous update, and I’d like to visit some of them now. At the time that post was written, it looked like the user experience for Twitter Tools was going to look something like this:
- Download, install and activate Twitter Tools.
- Click a link to twitter.com where you would have to register your WordPress site as an application.
- Take the two keys provided to you and go back to the Twitter Tools settings page. Copy-paste those keys into fields in the Twitter Tools admin page.
- Click another link to again visit twitter.com, this time to do the OAuth handshake and get your authentication tokens.
- Return to your WordPress admin and continue tweaking your settings, etc.
If you were able to succeed in these steps, everything would be set up.
The fact that I as a developer look at those steps and groan was an immediate red flag to me. I know all too well from years of email support questions that not all WordPress users are highly technical and a 4 step process with 2 steps that make you change sites and one that includes a copy-paste dance isn’t something that is going to make people happy.
Some people have suggested that this is just how it is and I have to deal with it. I disagree. When I see something that’s too hard I want to fix it, not perpetuate it. I sent an email outlining my concerns to the Twitter API team. They are smart folks, clearly they had been working on solutions for this situation as well. They have posted a proposed outline of a different workflow that looks to be an improvement over the previous situation. It’s an improvement, but it’s not enough.
I added the following to the thread:
This is excellent news and sounds like a much better user experience than the previously discussed options. I would like to suggest it be taken one step further. Could the encoded string with the keys be returned programatically to the Open Source application instead of asking the user to copy/paste? This way the user experience would be very similar to a standard OAuth transaction.
I really hope they make this change and provide the string with the tokens via a callback method/URL and allow us to completely skip the copy-paste step.
I don’t pretend to have thought through every situation that the Twitter API team is having to consider here. I’m focused squarely on my own little use case. My goal is simple: make the process of installing and configuring Twitter Tools as easy as possible for my WordPress users.
With what they have outlined and my suggestion above, I am hopeful that I will be able to support a user experience that looks something like this:
- Download, install and activate Twitter Tools.
- Click a button in the WordPress admin that registers your site with twitter.com and returns the necessary tokens to Twitter Tools.
- Click another link to again visit twitter.com, this time to do the OAuth handshake and get your authentication tokens.
- Return to your WordPress admin and continue tweaking your settings, etc.
The OAuth step is going to be required – there isn’t a way around that (and shouldn’t be). However I want the rest of the connection stuff should be as painless as possible for my users.
If you care about this, you might want to drop the Twitter API team a line (api@twitter.com or @twitterAPI) and encourage them to go one step further in their proposed implementation so that Twitter Tools can give you the easiest possible configuration experience.
My guess is that the OAuth deadline will be extended while this new API is being implemented and tested. I am currently holding off on my Twitter Tools integration until I see where things end up.
This post is part of the project: Twitter Tools. View the project timeline for more context on this post.
I went through the same exercise when I converted my browser-based Twitter application to support OAuth. Registering the application at Twitter is a one time event, but getting the consumer token keys is not automated. It involves cutting and pasting the keys to my scripts. I agree, I wish there was an easier way to automate it.
Ulysses – I understand the process, I’m saying it’s too much to ask of non-technical users.
Hey Alex,
Thanks for writing this up. OAuth in open source applications has largely existed in the theoretical realm until now — that is, the OAuth community has talked about the problem with embedding keys and secrets in open source apps, but we haven’t had a situation where resorting to scraping (i.e. maintaining the status quo) wasn’t the favorite alternative.
With Twitter upping the importance of account security by forcing apps to move to OAuth (a welcome step!), we’re now confronted with the reality of this situation.
So — to answer your question directly — no, I don’t believe this can be made simpler and still offer the same security characteristics that OAuth 1.0a provides. The reason that Twitter can’t return the key and application secret programmatically is because there’s a chance — ever so slight — that the user could be man-in-the-middled. This is actually why OAuth 1.0a exists:
http://oauth.net/advisories/2009-1/
The only way to avoid requiring the user to have to go to Twitter.com to get the keys and secret is to force them to use SSL on their site (the only way to prevent against MITM attacks) — a steep price for self-hosted WordPress blogs.
Additionally, one *benefit* of forcing the user to visit Twitter is to ensure that they’re signed in under the correct user account — presuming the user has more than one Twitter account. That extra step of confirming that they’re actually getting keys for the right account will probably save you more hassle over the long term than avoiding the double redirect step.
One optimization that I might suggest to Twitter is to embed a Flash app that you can click on to copy the key and secret to your clipboard — in one action — which would then (possible) redirect you back to the original blog. This won’t work if Flash is disabled of course, but for the users you’re worried about, I think you can take Flash for granted.
Curious to hear your thoughts.
Frankly, I think this sucks. I’m very frustrated that this change is resulting in a bunch of work on the part of the developers and a *huge* increase in hassle and difficulty in set-up and configuration for the end users (which then creates more support requests for the developers, etc.).
I’m having second thoughts about updating Twitter Tools at all to support this system.
But there’s a balance, right? They’re moving to OAuth for a number of reasons (monitoring, abusing blocking, security) but one of them is improving security.
It’s hard to improve security and maintain usability — I mean, something’s gotta give.
As a designer I definitely sympathize and feel your pain — but I know that many people got burned by having third party sites abuse their passwords. And since a site is only as secure as its weakest link, forcing everyone to move to OAuth is about increasing Twitter’s net security profile.
If Twitter offered the option, do you think that people would be willing to adopt SSL to a simpler experience (i.e. based on OAuth 2)?
The user experience would simply be better if you simply could call the /apps/new page with a few query parameter so that the user would not have to fill so many fields.
– redirect user to twitter/apps/new?callback=http://site.com&name=My+Application&etc…
– user reviews and clicks OK
Much less cumbersome than confusing the average Joe with all these stuff to cut and paste.
Chris – I agree, it isn’t easy. A couple of thoughts:
– I’d wager that less than 1% of WordPress installs have SSL enabled. I’d further guess that less than 3% would be willing/able to set it up – that number feels inflated too.
– Doesn’t OAuth pass back tokens over HTTP? Why does registering the app require a different level of security? Is it the difference between a request response and a new request? The MITM scenario is real, but it is very rare and there are mechanisms on both the user and Twitter side for disabling the app if that happens.
– Does Twitter really want ~500k WordPress app registrations? Because right now that’s what they are asking for.
I think we’ve gotten very close to a workable solution in their latest proposal. It’s got some usability trade-offs (especially compared to the current user experience), but I understand the reasons for moving in this direction and generally support them. I’m fighting for a little more rope so I can make things as easy as I can for my users within the framework of how OAuth operates.
As you (and others) have said, OAuth wasn’t exactly intended for this use case. We’re in square peg/round hole territory here – debating where to put the duct tape.
Ozh – that’s a good idea as well. I think we will get that in the new proposal. Of course, it isn’t explicitly called out, so that would be a worthwhile request.
Anytime you can make it simpler for people, you should. I know from experience of working many years with end-users that if something could be screwed up – it will be.
Kudos to you for making it easier for people!
Maybe a more friendly method would be to use the PIN-based oauth method.
That is the one used by Twitter desktop clients, and the user doesnt need to register the app again.
You can read more about this method here.
Alex, on further thought, your 4-step proposal sounds like the right one to aim for from a UX perspective.
I wonder if you could help design the API that you’d want to work with for Twitter and then propose it to them?
One more thing… I look around and it turns out that Google handles this in a rather smart way (IMO) by offering a generic key/secret pair: “anonymous”/”anonymous”. The docs are here:
http://code.google.c[...]SigningOAuth
Basically this has two consequences, however:
1. Google doesn’t force the developer through agreeing to the TOS. Not great, but a sacrifice that’s been accepted.
2. As a result, the authorization screen for any app that uses anonymous/anonymous as their key and secret displays a big scary warning that says that Google can’t verify the identity of the app requesting access to their stuff and the user should only proceed if they know what they’re doing — which for a WordPress admin who knows how to install plugins should be a sufficient warning.
Therefore, if Twitter were willing to adopt this solution, open source apps would just use anonymous/anonymous as their default key/secret, and the person who installs the plugin could choose to signup for their own key and secret if they wanted to avoid the nasty warning on the authz page.
This is a really interesting approach.
I was thinking more on the ability to programmatically register a site as a child app and realized that the downside is the inability to associate the child app with the user.
Perhaps a solution to that would be to have a special request type that does OAuth and child app registration in one step.
Ah, yeah it’s the child app thing that makes this very challenging… Essentially *some* kind of “identity” needs to be embedded in the open source app in order to be a “child”. Otherwise, you can’t say that this “app is so-and-so’s son”. But, that opens the potential for spoofing (not like it’s a big deal, but it’d be a possibility).
If open source apps didn’t care about maintaining a lineage, then the anonymous/anonymous solutions seems like it would be sufficient, right?
With anonymous/anonymous no app is registered at all – correct? I think the programatically registered child app is a superior option to that. But yes, with anon/anon support you’d just OAuth and go. That would be super easy.
This issue has been annoying me for quite some time. If you want to integrate an opensource plugin with a data-centric site as of late, you need to be a “developer”. You always have to visit the developer area and signup an application. The use cases and terminology is all wrong here, this is what’s really wrong and confuses people.
Interacting with facebook via your site, it’s the same deal, you must register your site as an application and take the keys back to the plugin. As much as it annoys me, i personally still feel it’s a necessary evil. Every time i think of a work around for current solutions, there’s some kind of security hole perpetuated by doing it. You guys also just laid down some really good alternate solutions and then found little holes in them.
Allowing the user to skip this annoying step is only ever possible when you can be sure your secret key for your app is safe and therefore can include your key for the user to use. Here’s a problem we’re going to be facing over and over again in the foreseeable future and eveyrone’s proposing band-aids and duct tape over OAuth.
Most of the things suffering from this seem to be websites (everything else is compiled, so they CAN protect the key) why can’t these website register themselves from the IP and Hostname they’re coming from?
Heres how i see it working:
– I install Twitter Tools
– Perhaps i click some authorize button
– It sends me to twitter
– “You have requested that http://www.blah.com @ xxx.xxx.xxx.xx signup for application access at twitter”
– Yes/No button
– Maybe boxes for some info
– Click yes, host @ ip authorized now authorized app, after X days without use authorization is revoked (taking into account a server move or something).
In a shared hosting environment, it’s plausible someone could spoof you and there’s no MITM because no data goes back in this process. I also think spoofing is only happening because people are doing dodgy stuff or they just don’t realise it’s YOUR secret when they’re ‘learning’ from your opensource code. So by making signup so transparent and using the dual hostname/ip i think a lot of the spoofing will go away.
Call me crazy, but I don’t think anybody who’s incapable of following a simple list of instructions to set up a Twitter application should be administering a website.
I continue to say that this is a non-problem, and you’re underestimating people.
Alternative: Ask them for xAuth access for your application. This will let you exchange the username/password for the necessary clent tokens in one step. No need for the user to make their own application.
More info: http://www.reynoldsf[...]rom-twitter/
Last week their xAuth page said something to the effect of “web applications will not be granted xAuth access”, but that appears to have been removed. Interesting.
Of course it does nothing to address app registration and/or distribution of app secrets.
I’ve been in discussion with the Twitter API team about some alternative solutions. I am optimistic.
No matter how easy you make something, there’s always someone who will fine it hard to figure out. You can only shoot for the best majority, and let the others, take longer to figure it out.
[…] it works out, and if the plugin still offers digests after it’s rewritten to use OAuth, I’ll probably use this same setup to make sure I keep on top of linkblogging at Speed […]
Hey Alex appreciate the post, and especially enjoyed the comments following it. What we are dealing with is a situation where publishers don’t want to be developers, and developers want to make it easier for regular folks to publish.
If oauth isn’t the right tool to make this happen, then some other tool will step up. The most well though security software in the world doesn’t do folks any good if no one uses it (or just a handful of devs use it).
Is there something we’re missing? (I dug the anonymous/anonymous solution it brought back ftp memories)
[…] Even Alex King, creator of Twitter Tools, has complained about it. Unfortunately, it’s my only option, so I’ve included detailed instructions on the […]
[…] Twitter changed a year ago to require OAuth for authentication, I said it would be a Bad Thing for users of Open Source tools like Twitter Tools. The process of creating an app sucks, I’ve […]
[…] Twitter Tools and OAuth Continued – June 13, 2010 […]