Designing RESTful login service

Question

I went through a similar question here. But I am yet not clear over concepts. Here is my scenario...

My client (a mobile device app) has a login screen to enter username, password. After submission, he should see the list of books in the database plus the list of books subscribed by that user.

I am having a /LoginService which accepts username, password & checks a mysql database for credential validation. Only after authorization....I have a /BookService ; GET on which returns all the books in database.

1. Should I use GET, POST or PUT on my loginservice ? Since a login request is a read-only operation, I should use GET - but this sounds stupid for browser(as the submitted data is visible).

2. What are accesstokens (mentioned in the linked answer above), and how to generate them using Java ? I am using Jersey for development. Are they a secure way of authorization ?

Thanks !

Answer 1

As far as I understand you are trying to implement stetefull communication between client and server. So you login with first request and then use some kind of token to make further requests.

Generally I can recommend you to have stateless communication. This means, that you authenticate and authorize each request. In this scenario you don't need LoginRestService. Important points here are:

1. Client can provide userName and password through HTTP Headers (non-standard, something like UserName: user and Password: secret).
2. At the server side you can use
   1. Use AOP: just wrap you BooksService with AuthAdvice (which you should write yourself). In advise you access somehow (with Jersey functionality) HTTP request, take correspondent headers from it, authenticate and authorize user (that you load from DB), put user in ThreadLocal (so that it would be available to the rest of your app) if needed and just invoke correspondent method or throw exception if something wrong with credentials.
   2. Use Jersey functionality: (sorry I'm not very familliar with Jersey, I'm using CXF, but conceptually it should be the same) just create some kind of AuthHendler and put it in request pre-processing pipeline. In this handler you need tho make exactly the same as in AuthAdvice

Now each of your request would be authenticated and authorized when it reaches BooksService. Generally stateless implementation is much better for scalability.

If you want to go statefull way, than you can just use HttpSession. LoginService.login() should be POST request because you actually making some side-effects at the server. Service will perform authentication of your user according to provided username and password and put loaded User object to session. At this point, the server side session is created and client has session ID in the cookies. So further requests should automatically send it to the server. In order to authorize requests to BooksService you still need some kind of Advice of Handler (see stateless solution). The only difference: this time user is taken from the HttpSession (you should check that you are logged in!).

Update: And use HTTPS! :)

Answer 2

I've got nothing to dispute in Easy Angel's answer, but got the impression you'd like some additional comment on the concepts too.

The problem is clearer if you think in terms of resources rather than services. Think of your proposed login as generating a new authorization resource, rather than querying a login service. Then you see that POST makes perfect sense.

The authorization token would be a key for your user into the session object (as explained in EA's answer). You'd probably want to generate it by concatenating some information that uniquely identifies that user and hashing it. I certainly agree that a stateless authentication method would be preferable, if you're aiming to get all the benefits of REST.

Answer 3

Use what is available in HTTP: HTTP AUTH over SSL. Protect all your resources with HTTP AUTH and the browser will take care of providing a login for the user.

If you need session information on top of that, use cookies or a session parameter. Cookies were made for exactly these kinds of purposes and usually work well.