6

What is the best way to do Twitter OAuth authentication safely in JavaScript?

I am trying to write a program to let the user analyze his Twitter usage and followers / friends. I've written a server side version which works using the python tweepy module.

I would like to share it with people, but I would like it to run in the browser to be scalable vs. running on my small server.

I see another question where the upshot is that it's not recommended and not safe: JavaScript OAuth sign in with Twitter

Which makes sense if one were sending the consumer (app) secret or access (user) secret in the app's JavaScript.

But why couldn't I build the URL on the server side like here - http://djangosnippets.org/snippets/1353/

Then send the authentication URL back to the browser, something like this from the OAuth Tool on Twitter's My Applications page (not valid credentials)

GET&https%3A%2F%2Fapi.twitter.com%2F1%2F&get%252Faccount%252Fverify_credentials_json%3D%26oauth_consumer_key%GD0bgcgMU4MDwNfKQpLFQS3%26oauth_nonce%3D24ad5049501dee1292afd8cf22307d68%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1329173626%26oauth_token%uPUpxsBc3D283768289LtQ6R1Ez1KeD8DOSsm5XpqJaKI28ysYh%26oauth_version%3D1.0

Then have jQuery use that to authenticate with the user's credentials and run the analysis.

It's a significant piece of work, I'd hate to do that and then find out it doesn't work or is an unsafe approach. (or it's already been done)

Is that safe? It doesn't seem to expose any secrets.

Will that work?

Any pointers/examples on the right way to do the authentication for a jQuery noob, with the necessary Authorization: header and cookie/redirect processing?

I feel like I'm missing something and either there's a reason this won't work, or it should already exist somewhere, but haven't found it. Many thanks!

Community
  • 1
  • 1
Rocky McNuts
  • 183
  • 2
  • 9

2 Answers2

3

The problem Mr. McNuts, is that the oAuth requires you to pass in your consumer secret, so even if you build the URL on the server, you'll still pass it back to the webpage, which will still expose your consumer secret via an HTTP Proxy.

To prevent exposing your secret, you'll need to use a proxy to do the twitter auth request, and return the oauth token back to the browser. If you're really worried about scale, I would look at a pay-for-scale solution like GAE or Heroku.

Alan
  • 45,915
  • 17
  • 113
  • 134
  • I thought the point of splitting the consumer key and consumer secret was that you could expose the key, and no one can do anything without the secret. What could someone do with just the consumer key, if they didn't have the consumer secret? – Rocky McNuts Feb 14 '12 at 00:36
  • Yes, you're right. What you're essentially proposing is to have your server sign using your consumer secret, then pass that back to the client. You could do that, but it's not any more scalable than just having your server make the request on behalf of the user. – Alan Feb 14 '12 at 01:22
  • Yes, basically I want to proxy the authentication, and then have the browser do a bunch of API calls. It's going to be a few hundred calls, right up to the throttling limits. Plus they will take a long time and tie up resources while they're running. So I really prefer not to do it on the server, will be orders of magnitude more load. Would like to pass back an URL or token to the browser, and then use that to make API calls with jQuery or pure JavaScript. – Rocky McNuts Feb 14 '12 at 01:32
  • You should be able to pass the token back to the browser and have that interact with twitter. You only need to proxy for auth. – Alan Feb 14 '12 at 01:57
  • Thanks Alan - am thinking feasible and safe... now I just need to figure out how to format the API calls with JS / jQuery after I have the token. – Rocky McNuts Feb 14 '12 at 04:48
  • I get it now. Every API request doesn't have to **send** the secrets, but the request has to be **signed** using **(consumer_secret & auth_secret)**. So I would either have to put the consumer secret in the JavaScript so it could sign the request (unsafe) or have my server sign each API call (pointless, might as well just have server do the whole API call). The part I was missing was that you have to sign using the secrets. – Rocky McNuts Feb 15 '12 at 03:26
  • This was helpful in understanding the OAuth flow: http://blog.andydenmark.com/2009/03/how-to-build-oauth-consumer.html . Includes python code, and there is also PHP code here: http://stackoverflow.com/questions/3295466/another-twitter-oauth-curl-access-token-request-that-fails/3327391#3327391 – Rocky McNuts Feb 15 '12 at 03:31
0

I don't understand very well the approach you are proposing. But in general terms OAuth can not be done safely implemented on a browser client side (except secure close environments like Java or Flash). Implementing OAuth process on Javascript is quite possible but you will expose your secret/consumer token. So anybody would be able to supplant your application identify with mischievous intentions like stealing your users sensitive data. If you still want to work with JS, I recommend you to implement the secure process (authentification and final token storage) on server side using Node.js

Veilkrand
  • 325
  • 1
  • 3
  • 16