3

I have a web API that accepts Authorization headers to allow access. It responds with the requested data in addition to setting a session cookie. Subsequent requests can be made with no auth headers as the cookie is used in its stead.

Originally, no auth was handled on the node server. API requests were all made directly from browser. This made auth simple, as the client entered user/pass was sent directly in headers and received a session cookie in return.

Now, however, we would like to move towards doing initial payload rendering on the server. This will require both the Server and Client to be "authorized" with web API. What are some common approaches to doing this?

A couple of possibilities that occurred to me:

  • Client auths with API as before, API sets cookie for future browser requests, client copies cookie to node server (which stores in session) for use in future server requests.
  • Client sends user/pass to node server, node server auths and stores cookie in session, all subsequent API calls run through node server.
  • Client sends user/pass to node server, client auths normally, node server auths normally.

First option seems ideal (if possible). This is how I would imagine one would use an "access token". Is it possible to use cookies like this? Are there cross origin restrictions that pertain to cookies that I am overlooking? For instance, I know that this does not work the other way around (I cannot auth on server, put API cookie in response to browser, and have the client use that cookie for a different path (the web API instead of the node server).

Second option I really want to avoid as it seems like a lot of unnecessary traffic on the node server, a lot of boilerplate routes, and our web API is already very simple to use directly from browser. Performance wise, this also adds one additional stop. Ideally, the node server should be serving page requests and thats it.

Third option just seems kind of silly. It results in the same user being authed in multiple places, which the web API may or may not like (I didn't design it nor do I know its inner working). We are also sending username password over the wire twice (which logically seems less secure than once).

Any other suggestions are welcome!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.