CODEWITHSUNDEEP
javascriptrestbackbone.js
DivinesLight
DivinesLight

Reputation: 2415

Secure Access to Authenticated REST Server through Backbone.js?

I've had this REST Server (written by myself) that is secured by simple HTTP Authentication.

Now I re-wrote the app using backbone.js and I am unsure how to go about authenticating my client. If i do it in JS user/pass would be visible.

So how should I modify my server or my client side JS to be secure?

Previously I just gave user & pass in PHP for each request to REST Server, please guide me, Thanks.

Upvotes: 15

Views: 11785

Answers (3)

geekgugi
geekgugi

Reputation: 389

If you have access to your server side REST code, you can redesign REST authentication. First time, to login you post username/password over https, in turn obtain a session id which can be used in subsequent requests passing it as cookie.

Upvotes: 0

DivinesLight
DivinesLight

Reputation: 2415

Okay I had a discussion with my colleague and came up with the best idea so far:

Make a simple controller in your Client Side (site) and name it as RESTAPI, it will just act as a wrapper to your actual REST Server.

When a user logs into your site, his session get's created. The RESTAPI controller knows credentials to your HTTP Authed actual REST server and it hits REST Server on backbone's behalf.

Example: If I have to fetch

/messages/sent

from REST Server, now instead i'll hit this url in backbone collection

site/restapi/messages/sent

The RESTAPI Controller also first checks that the requesting user has a proper session on the site and weather he is allowed to fetch the resource or not.

So no worries about insecure cookies or leaving your REST Server pass in plain JS or using any other obscure method :)

Upvotes: 2

PhD
PhD

Reputation: 11334

HTTP Basic authentication is prone to eavesdropping and man-in-the-middle attacks. It's recommended to use HTTPS.

However, if that's not an option you can always send a cookie back to the client and have the username/password entered there to prevent it from being displayed in the JS file. Goes without saying that the password should at least be encrypted/hashed for security reasons. Then, the onus will be on the server side to get the authentication details from the cookie.

Now, if you don't have any control on modifying the server side code, you are pretty much left with no option other than burying the credential details in a global ajaxSend() method that will send the username/password details with every AJAX request. You could just put this in some other .js file and make it hard to find, but you are pretty much restricted to that form of security. Although, cookies don't make your life any safer. (It'd be good if the password is hashed/encrypted).

The other thing you could do is to have a slightly more complicated form of security: Have the server send a nonce back with every response - the nonce would be 'signed' by the server using the server's secret key and you can use that to 'encrypt' the username/password on the client side for every request. Your server would then have to constantly decrypt the credentials. This is less prone to man-in-the-middle but still not foolproof.

HTTPS would save you from each of the above if it's an option for you.

Hope this helps.

UPDATE (as per comment): The essence of restful-ness is the absence of state on the server. I.e., no sessions! Hence you need to send the user credentials with EVERY request the client makes of the server. If you have a login page then it's very hard to be truly restful since there is no 'resource' called login. However, here's what you can do:

  1. User visits login page, enters credentials and clicks 'login'
  2. Send POST request to server with these credentials - probably to /Login
  3. Have the server return the requested resource for which authentication was needed AND set the cookie with the valid credentials to use in the 'next' request
  4. Every subsequent request will be directed to the corresponding resource at a particular URL with a particular action (GET, PUT, POST, DELETE...). The server should check the authentication data from the cookie and decide if the user is authenticated and perform further authorization to grant access if the need be.

Every request must identify itself without having the server maintain the session - that's the spirit of statelessness (and restful-ness ;)

Upvotes: 29

Related Questions