Best way to secure javascript front end/REST back end architecture web site?

Question

I would like to build the following project:

• public REST API back end which can be accessed by any authenticated client.
• front end with static files in HTML/CSS/Javascript with Backbone.js jQuery calls to the REST back end.

In fact, there are three parties in my architecture : the front end, which is a client of the back end, the back end and the user which wants to authenticate on the front end login page.

What is the best way to secure the three parties involved in this architecture?

In fact, I believe it is just impossible to do a secure app on the front end if I do everything in javascript, so I intend to delegate the authentication/authorization to a proxy layer on my server front end.

My problem is I don't know how to perform this workflow with OAuth :

• a user wants to create an account on the Front end.
• the Front end delegate the account creation to the REST back end.
• the back end create the account and send an ack to the front.
• then the user can perform calls which require authorization.

And I also want my REST back end be accessible to any other third party application whith OAuth.

Will I have to use 2-legged or 3-legged OAuth on the REST back end?

Can I consider my Front end just like a special third party application which has the ability to create user account ?

What security protocol may I have to use on Front end ?

Answer 1

Well, since you state that the REST API can be accessed only by authenticated clients you will firstly require a form of sessions to remember the authentication state of the client. Depending on whether you can alter the server code of the REST API you could implement this on the API providing server itself.

This could use any of the well known user authentication means like a username/password combination or using a (self-signed) certificate.

However just like with HTTP you will have to make sure that passwords don't travel the line in plaintext and once the session is authenticated the connection should not leak the session identifier allowing for it to be hijacked. This basically means you have to mimic SSL-like behaviour or implement SSL support for your front-end. An example can be found here: http://assl.sullof.com/assl/

Your questions related to OAuth are a different question and I would suggest you ask that in a separate question if it still remains something you want to know.

With regards to a proxy layer, this is a viable option only as long as the API is not publicly accessible other than through such a proxy. This proxy layer would have to implement the same SSL-like properties but this setup gives you the added feature of being able to keep the authentication logic and the API provider separated. However I would not recommend it if you are able to alter the API, because if any part of your server accidentally provides access to the private API you can circumvent your authentication requirements.