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)?
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.