OAuth-only Twitter: What it Means for JavaScript Apps

Today could be the last day for some web applications built purely with client-side JavaScript and the Twitter API.  According to Twitter, Basic Authentication has been permanently shut off, as promised. While the move should bring better security for many users,  it will also make building JavaScript apps without server-side support for OAuth practically impossible due to security issues.

Developers that are using JavaScript to create client-side only applications find themselves in a catch 22. The OAuth information would have to be hard coded, which removes the extra security of using OAuth. Anyone using the app will potentially have full access to the developer's account. Twitter's Taylor Singletary described the problem on the developer mailing list:

There is no secure method to accomplish this purely in Javascript, as you would have to hard code your consumer key & consumer secret as well as an oauth_token and oauth_token_secret for the Twitter account you want to use for all operations. With these pieces of information, anyone would be able to tweet on behalf of your application and account.

In a case like this, you'd want to implement most of this logic server-side, where you can keep the hard-coded credentials securely. You could potentially use Javascript to speak to your own servers to hustle the process along.

Yes, this change will lead to better security because important information never leaves the server. It also has the effect of reducing the number of options for creating a JavaScript app. However, those using the search API with JavaScript will be unaffected, as it does not require authentication.

Twitter OAuth countdown clock

Developers have had plenty of warning. Twitter first announced the move in April, then extended the deadline from June to August and finally implemented a gradual phase-out. Twitter appears to be letting a trickle of connections through with the old method, but expect even that to end soon, as the company's statements all point to Basic Auth being really, truly gone.

The change to OAuth means increased security for users because "Applications won’t store your username and password, and if you change your password, applications will continue to work." OAuth is a token based authentication system. Individual applications are granted access through a key passed from the server. Applications that use Basic Authentication store the password in the app and send it to the server when they make a call.

Is giving up client-side-only applications significant? Is it worth the security? Let us know in the comments.

Be sure to read the next Security article: How Developers Can Help Prevent "Social Burglaries"


Comments (11)



Google Chrome extensions are web apps. Calling external javascript files is not the same as installing an app for OAuth. Their wrapper is used to handle the handshake needed for OAuth services like Twitter. Their is no connection to a server in this process except for the call to authorize the user to Twitter's API.

@Luciano: It's interesting that months after this happened developers are still wrestling with this issue. I'm constantly astonished by developer ingenuity, however, a really good solution for doing this hasn't presented itself. On one side you lose security and on the other you go with oauth of one type or another. Still waiting for a good way to handle it but haven't seen anything definitive.


Are you sure that the tutorial you linked to applies in this situation? It seems to be directed at desktop apps and not web apps. I was addressing JavaScript apps that are downloaded from a website with no further connection to the server. Are you saying that installed app OAuth should be used for web apps?

In some of my research for the story I found solutions where people suggested using ssh to encrypt the information. This sounds like a great deal of trouble to me (but might not to everyone). It seems like most folks will give up on this type of application.

Developers are crafty and where there is a will there is a way. If you uncover the secret to doing it easily I would love to hear about it.


I wanted to create an webapp wich is mostly based on JS. I used YQL to accomplish that, it was pretty easy to create a table for the job - and to store my keys in the storage.

If we do Twitter Oauth at server side can't we get rate limit?


Thank you for your follow up comments and that clarification.


This is why they launched @anywhere. Just like facebook connect, there's no need for server-side technologies. Pure JavaScript magic! :)


Are you sure OAuth cannot be done through client-side Javascript apps? I have accomplished this before using an OAuth wrapper. Also, Google Chrome has a tutorial on this:


Maybe I am mistaken, and someone can show me why it can't be done.


"Is giving up client-side-only applications significant?"

Client-side-only is a bad idea, anyway.

The beauty of the API is the opportunity for platform independence. Calling twitter at the server side opens your app up to c-level browsers (including Blackberries and dumpy old flip phones). You can then layer JS on top of that, purely to make the experience prettier or more compelling for those devices that support JS.

@Felix: And how do you accomplish that? to access private data in your YQL tables Yahoo uses OAuth..

I am thinking a lot about this and all the javascript method seems to be unsecured to me. There is no way to store securely the data into a JavaScript file. You can use SSL connection and whatever, but it will be visible in the client side the same way.

Anyone has any tip? What can be done?

I thought about using a server proxy. I store my credentials in a php file and connected through an Ajax to my server. But anyone can use my server as long as it knows the address....