2

I've been looking around for an answer to this question, but it looks like that nobody does this. Imagine you are designing a javascript REST client, and you want to create a login page. Surely, after the login you will be authenticated.

So the following requests to the REST API will depend on your current user id, which should be stored on the client side following the RESTful way.

My question is how to store this "session" information using Javascript. I've looked into cookies, but it seems to me too much plain text for one to trust. Also using cookies one could store there an session id that maps to the user information on the server, but this violates the Stateless concept from REST.

Which the best approach to solve this problem?

Paulo Victor
  • 906
  • 2
  • 10
  • 18
  • 1
    See http://stackoverflow.com/questions/6068113/do-sessions-really-violate-restfulness for an excellent explanation of REST and states. – potatosalad May 02 '13 at 04:53

1 Answers1

1

We are also building similar kind of architecture where RESTful API will be accessed by a javascript client.

We will authenticate client with client credentials and generate an authentication token and that will be sent to client. Client will store it in cookie or in local data store. Further requests to API from this client will be sent using HTTP authorization header and including that token in the header. We will authorize the request at API end for the given token and request will be served once it is authenticated.

Until n unless you don't access cookie information on server side I don't think this will violate stateless principle of REST as we are not maintaining any state of the client on server (we are but not binding it to any server). Regarding the authentication process using token, I don't think we are binding the server and client here, because we have multiple servers and using load balancer and still this request may be served by any server (similar to Google api).

Note: We are doing this using HTTPS protocol so we are sure that all this communication is secured.

JPReddy
  • 63,233
  • 16
  • 64
  • 93
  • I see, and it makes sense, thanks for the clear answer. But I have another question: imagine that Paul logs in a system. The server send him an authentication token. Lets imagine that Paul wants to see his profile, resulting in an API call such as /profile/{paulId}. How can we store this id in the client side? Or we use the token and translate it to the Id? – Paulo Victor May 05 '13 at 06:47
  • 1
    After initial authentication next accessible URI should be available for client and server should send that URI. Client should never be able to generate any URI on its own to access a server resource. If that is the case then you are breaking rest principle (HATEOAS) and your server is not able to modify resource state. Read about HATEOAS. In the above case your server should give all the URI's to proceed further including the URI to this user profile, this depends on your application state after authentication. – JPReddy May 05 '13 at 17:44
  • You're right. I'm from the "time" that the RESTful Java Frameworks didn't support HATEOAS, so I completely ignore it. – Paulo Victor May 06 '13 at 00:14