How it is possible to not expose you secret key wi

2019-03-10 20:46发布

问题:

Looking at Twitter OAuth Libraries, I saw this note:

Be cautious when using JavaScript with OAuth. Don't expose your keys.

Then, looking at jsOAuth examples, I noticed that the keys are exposed in the code.

So my question is: How it is possible to not expose your keys when you use an OAuth library in Javascript?

Thanks.

UPDATE: Ok, maybe jsOAuth is not the right library to use, but how it is possible to do authentication with OAuth on a full Javascript web site?

回答1:

As said in the documentation linked by you:

Written in JavaScript, jsOAuth aims to be a fully featured open source OAuth library for use in Adobe AIR, Appcelerator Titanium and PhoneGAP. In fact, anywhere that javascript can be used and has cross-domain XMLHttpRequests. For security reasons jsOAuth doesn't run in the browser. Browsers are only mentioned here for running the test suite. If you need jsOAuth in the browser, write an extension.


A good answer to your added question is available here:

  • Secure OAuth in Javascript


回答2:

The only really reasonable way, right now, to do OAuth 1 in the browser, is to route API-calls via your server.

There simply is no way, as far as I have understood it, around this. If you do OAuth 1.0a calls through JavaScript from the browser -> You will HAVE to expose your consumer secret and access token secret, to at least the end user.

You cannot store these credentials in:

  • a cookie, the user can find them.
  • local storage, the user can find them (better than cookie though, since it does not entail sending a cookie back and forth all the time over HTTP)
  • in javascript, the user can find them (although this is probably your best bet since it is easier to obscure).

If it were only the access token secret that was exposed to the end user, that would be bearable - since it is in fact he/she who have authenticated your application. But losing your consumer secret is really not so hot, it means that your application is eligible for identity theft. I.e someone else could write an app that claims to be your app.

Even if you made it work securely in the browser, you are hampered by cross domain security blocks.



回答3:

You could also make a script that sends all necessary values and parameters to the server to do the signing with.

The signed URL can then be sent back to the client (browser) that in turn does the actual request.

I have implemented OAuth 1.0a on the Twitter API that way using jsonp requests. The benefit of this is that the response body is not relayed via your server, saving bandwidth.

That way you can have your cookie and eat it too.