Bypassing the same origin policy for authenticated XmlHttpRequests

Question

I have a site on foo.com serving PageA .

PageA has some jQuery inside it that requests through XmlHttpRequest some JSON data from the CouchDb instance located at bar.com .

As I understand it, the same origin policy prevents this, but using JSONP should circumvent this limitation (CORS will eventually cover this use case).

The foo.com server has a reliable connection to the bar.com database.

Is it possible to authenticate a user with foo.com using their OAuth credentials (for example, to log in to Twitter) and then use bar.com for authentication? (I believe this is not due to the fact that the authentication cookie is only read by foo.com .)

Given this, is it possible to authenticate the user in any way to use CouchDB at bar.com from foo.com using any of the available authentication mechanisms for CouchDB (OAuth, cookie, and Basic)?

Edit: Can I, for example, return the user credentials for bar.com from foo.com (extracted via my trusted link), which are then set on the client side in the XmlHttpRequest HTTP header for basic authentication with bar.com . Of course, everything is done using TLS (... or is it a security nightmare?)

Answer 1

I had the same issue regarding the same origin policy in xhr. I had a website and I wanted to populate the autocomplete content with JSON data from another server running CouchDB.

There are two ways:

• JSONP - it works just fine
• CouchDB proxy through the main web server - this works fine from the point of view of the b / c client, everything is on the same host. It also makes SSL doable.

As for exchanging a login session with CouchDB and another application server, I don’t know how to do this without resorting to basic HTTP authentication, which is actually not so secure. It is probably better for the application server to work as the middle-class client b / t and CouchDB.

Another advantage of a medium-sized application server is that a single CouchDB database can have documents for multiple users. In contrast, if a client accesses CouchDB directly, you probably need to create a separate database for each user using filtered replication so that one user cannot view other user documents.

Answer 2

From my POV, even JSONP is a security risk - so I just wouldn't go that route ...

To achieve what you are asking for, I see two options (both can be made to work with SSL, if necessary!):

• write your own web service / REST / SOAP / everything that works on foo.com and interacts on your behalf with bar.com for authenticated clients

• use the "general HTTP proxy" that runs on foo.com and displays bar.com so that your application / page works as if CouchDB works on bar.com for authenticated clients

Answer 3

You can inspire facebook server authentication by substituting a client for your client, a server for foo.com and facebook for bar.com. See http://developers.facebook.com/docs/authentication . Thus, the client had to be authenticated to use the data from bar.com (in the script downloaded from bar.com, of course, but you can pass the data for the callback from foo.com, if I'm not mistaken).

Answer 4

As I understand it, you want to use JSONP from foo.com to make requests to bar.com as long as you want bar.com to know if this request has already been authenticated by foo.com or not.

This is similar to logging in to foo.com and being able to migrate authenticity to bar.com.

Assuming that XMLHttpRequest can remember the session identifier in the cookie of the rest of the requests, how about using a one-time password (actually a random string, we can call it a token) that made bar.com call from the page generated by foo.com after logging in, as below:

 login request -> foo.com -> XHR(bar.com, OTP) -> bar.com cookie updated with an active session id <- bar.com XHR(bar.com, CounchDB) -> bar.com successfully 

So, if foo.com and bar.com can communicate privately (and securely!), Foo.com can generate OTP and send it to bar.com so that bar.com knows that only a valid user can know this and therefore can process Session identifier as authenticated.

Alternative courses:

• If the cookie used by XMLHttpRequest for bar.com is not stored in the requests, the same OTP must be passed in each request.
• bar.com should provide a service for monitoring authorization authorization from foo.com for newly added OTP. It must have some timeout mechanism in order to invalidate old tokens.
• bar.com may also require the provision of an authentication removal service, as well as to prevent risks when using public machines.