8

As per REST spec, the service is supposed to be stateless; but then it becomes difficult to enable authentication. Some of the stuff I have read said "making REST stateful is not end of the world". But that's not the point, the point is to follow the spec and be consistent.

So, I am asking this question here in a hope someone could guide me in the right direction. I am working with Spring MVC to create a REST Service. I do not have views. It is a true REST Service which consumes/produces JSON. I need to have authentication (and authorization down the road) mechanism for this application that is stateless and follows REST specification. The client will be written in JavaScript (Backbone.js, CoffeeScript) and will accept username/password from a User. Then it will post that information to the server.

How can I achieve true stateless authentication (and authorization) in a Spring based application?

Digest Authentication over SSL - Is this the way to go?

abatishchev
  • 98,240
  • 88
  • 296
  • 433
jsf
  • 2,851
  • 9
  • 30
  • 33
  • 1
    What is this "REST spec" of which you speak? It's a design pattern and a set of guidelines, not a specification. – skaffman Feb 10 '12 at 10:13

3 Answers3

2

Session management is different from the state management.

You server side during the handshake can generate a token and every time the client makes call it will have to add that token either to the head or else where for your server to be able to analyze and decide if you can allow the call to continue on.

Server does not need to maintain any state to check the validity of that token that can be done using some algorithm .

Shahzeb
  • 4,745
  • 4
  • 27
  • 40
  • And how can you achieve that on the server side ? – ndeverge Feb 09 '12 at 09:27
  • but then if the algorithm is cracked somehow, any token can be sent to access resources – jsf Feb 10 '12 at 16:55
  • You should also encrypt that token it could simply be hashed or salted hash ;) (basically hash of the hash).And that's where they zero day protection kicks in but if you are using a standard encryption algorithm and someone cracks it then there is major problem for industry more than your own application. Using SSL will ensure packets go untampered but using SSL is not necessary.We have seen FBI,Jboss and Sony etc getting compromised so yes it is not impossible but using standard good practices will make sure that average joe can not hack into it. – Shahzeb Feb 12 '12 at 23:03
2

Have you looked into how Spring Security works ? Using Spring Security I have been able to add custom HTTP Authorization Headers from the client in the REST Request. This is extracted server side, the requesting user is authenticated, and it is possible to authorize access to specific resources.

stoffer
  • 2,317
  • 2
  • 18
  • 24
1

You can use either Basic or Digest authentication over SSL, neither of which implies anything significant about the state. There may also be a cookie sent back by the server, which your client will need to send back when it does further requests (I believe that the Javascript code will handle all that for you). There are other authentication mechanisms possible, but they're more complex and not necessarily suitable. (The other key proper-stateless one is client-authenticated SSL, but that requires the browser to have a client SSL keypair installed and for the server to know what that identity means and it's quite a bit more complex to deploy.)

On the server side, use Spring Security as that makes it pretty easy to handle all this stuff. It works well with Spring MVC.

Donal Fellows
  • 133,037
  • 18
  • 149
  • 215