For Developers: OAuth Insecurity

I decided that, while working on the new API, I would take the opportunity to explain a bit about the foundations of the software since I am ultimately having to rethink every detail as I redesign the framework. I'd like to start off by talking about what I consider one of the key concepts of the extension - the fact that OAuth is not used in any portion of Clip and Share.

OAuth has become one of those fundamentals that just about every developer working on a social media platform has become familiar with. It has given developers the opportunity to get a key that unlocks the door without letting them steal your car in the process. It's really been quite a great influence on the way we even do something as simple as logging into a site. Even the SourceForge site you're reading this on right now has an option to sign in using an OAuth connection to some network or another.

So, why did I avoid using OAuth in Clip and Share? Why have I been so adamant about not using such a great technology? The answer is actually quite simple: It has a lot of shortcomings when JavaScript is involved. Almost all of the code that goes into Clip and Share could be considered "front-facing." The little that isn't is just a simple server routine that thanks you for using the software - and THAT wasn't even significant enough to include in the open source release!

OAuth just doesn't work when all of your code is front-facing. I really prefer that people don't have access to the secret keys that are used to encrypt connections to Twitter or Tumblr. Especially when they have write access! But there is another concern that may seem trivial to most: dialogs provide the user with a certain degree of secure feeling. The average end-user is going to be much more likely to enter information into a Facebook dialog box than they are to enter information in a generic dialog box that "promises" to post to Facebook.

Sure, some apps get away with this all the time and it works great for them. But if I install a Chrome extension that starts asking me to approve write access to all of my social media accounts, I'm going to really step back and reconsider using it!

There's yet another advantage to using share dialogs rather than OAuth-secured write access. Dialogs allow the software to be built up much quicker. If I were still using OAuth for each site that Clip and Share supports, it wouldn't cover as wide of an audience as it currently does.

I'm far from being opposed to the idea of using OAuth. I just haven't found a need great enough to warrant its implementation up to this point. The opportunity cost is just too high! So, for now, I'm keeping things simple and scalable!

Jordan Meyer, Project Manager