• Post Reply Bookmark Topic Watch Topic
  • New Topic

Are logins possible while being fully RESTful?

 
Rob Wehrstein
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If a session is stateful, then it is not REST compliant. Having a user login makes sessions stateful and, therefore, not RESTful, correct? Is REST more of an approach and web applications themselves are rarely fully REST compliant? I can think of a multitude of security issues that would result from sessions being stateless.
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you are trying to read too much into the idea of REST architecture.

REST is an architectural idea to help you keep straight the uses of HTTP methods and headers.

Bill
 
Ron McLeod
Saloon Keeper
Posts: 1263
131
Android Angular Framework Eclipse IDE Java Linux MySQL Database Redhat TypeScript
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Wehrstein wrote:If a session is stateful, then it is not REST compliant. Having a user login makes sessions stateful and, therefore, not RESTful, correct? Is REST more of an approach and web applications themselves are rarely fully REST compliant? I can think of a multitude of security issues that would result from sessions being stateless.

RESTful services don't have sessions - each transaction begins with a request, and ends with a response.

If the service requires authentication (and then authorization based on the authenticated user), then the client needs to provide all the necessary information to the server with each request. One approach is to maintain a shared secret that both the client and the server know, and have the client generate a HMAC using the shared secret to hash a combination of method, content type, date, path, and possibily a separate hash of the contents/body. When the server receives the request, it will calculate a HMAC based on the same inputs, and compare the result with what was provided by the client. If they are the same, the user is authenticated.

A request might look something like this:
   PUT /echo HTTP/1.1
   Content-Type: application/json
   Date: Mon, 19 Oct 2015 06:54:47 GMT
   User-Agent: Jersey/2.19 (HttpUrlConnection 1.8.0_45)

   Content-MD5: FVtQxudXSXjuBNZ71I5TDw==
   Authorization: hmac ron:rMQUa8efwhjTWzCH5mVpHWK3j210LP+dYFJXNsbL1/Y=
   Host: 192.168.100.141:8080
   Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
   Connection: keep-alive
   Content-Length: 32
   {"message":"This is my message"}


Including the method (PUT), the path (/echo), and the content type (application/json) in the hash, ensures that a mailicious (MIM) entity cannot alter the type of request that the client is making. By hashing the content (FVtQxudXSXjuBNZ71I5TDw==), and including it in the HMAC, the integrity of the of request body can be confirmed. And by including the date (Mon, 19 Oct 2015 06:54:47 GMT) in the HMAC, the opportunity for message replay is limited to the difference which the server will tolerate between the date/time provided by the client and it's own date/time.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!