1

Background

Lets say I want to use twitter's javascript api. The twitter javascript api says

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

It sounds like using javascript with OAuth is insecure [2]. Not due to network concerns (https can be used), but due to the fact that users who have access to view-source can also view your keys which are hard-coded in javascript. With these keys a user could then have control to your twitter account independent of your app!

The best approach I've seen is using YQL [3]. But what about doing this on your own server.

Is the following scenario secure or obscure?

Scenario

I'm planning on using twitter's javascript api to control access to my twitter account.

To solve the problem of allowing users view-source access to my api credentials, lets say I funnel all twitter api communication through a single public facing page, say Post.php. To prevent all users from having access to this page I could require a guid in the url: Post.php?pass=91626979-FB5C-439A-BBA3-7715ED647504

The server-side application would make an http request to to this page as the unique guid is known on the server.

The api communication could remain in javascript, while access to that javascript is secured through a server known guid. The http request is initiated on the server so there's no way to view the request by looking at traffic. The guid would not be included in the client's source. The client would make a request to a server function that then does a server side http request to Post.php

This would essentially cause Post.php to be inaccessible from the browser. In essence the server would be initiating the javascript api calls.

Is this secure, or obscure? Do you have a better approach (via javascript of course)?

coder
  • 1,274
  • 1
  • 13
  • 19
  • When you say "To prevent all users from having access to this page I could require a guid in the url: Post.php?pass=91626979-FB5C-439A-BBA3-7715ED647504" is this a server-to-server communication, or web-client to server communication? it is not clear in your post. Anything the client sends to the server must be considered unsecured. – Matt Apr 20 '12 at 16:23
  • the client would only send an onclick event (such as ClientClick.php). This server event would then make a server side http request to Post with the guid. The guid would only be known on the server, and would only be used on the server. – coder Apr 20 '12 at 16:27

1 Answers1

1

Updating given explanation below: Yep thats fine. You have a server that the client is authenticated to via login and the server handles posting to twitter. Since only your trusted server has the twitter credentials, clients can only go through it.

works fine.

imichaelmiers
  • 3,449
  • 2
  • 19
  • 25
  • The source and the client would never have access to the guid. It would only be known on the server. Post.php would never be visited in the browser, only via server side http request – coder Apr 20 '12 at 16:17
  • Yeah I miss understood what you were saying. How are you authenticating the client in the end? (i.e. the javascript talking to your server that makes the request) – imichaelmiers Apr 20 '12 at 16:20
  • The client would be authenticated via regular login.. but i'd want to protect the twitter credentials since they would be hardcoded in javascript. The client might click a button that says post.. goes to ClientPost.php. ClientPost.php then makes a server side http request to Post.php – coder Apr 20 '12 at 16:21
  • I'd advise using HTTPS -- you don't want to send that JavaScript (which includes your credentials) in the clear over the network. – apsillers Apr 20 '12 at 16:27
  • HTTPS would be used. This is not to protect from network sniffers but from the clients themselves. If the clients had view-source access to the javascript hardcoded credentials then they could make twitter posts independent of the app (i.e. would no longer need to go through the app's authentication) – coder Apr 20 '12 at 16:28
  • Thanks, let me know if you can think of a better way to do this. Keep in mind the primary security concern is I do not trust the users even after they log in! (they would have the information to modify the twitter account outside the app) – coder Apr 20 '12 at 18:25