4

I'm writing a REST API server(using Rails), and here is a question about session management.

I think for a REST API server, we don't need to save the log in state(or session) for each user. So I just add an authentication token for each user. If they log in, this server will return this token to them, and if log out, destroy it.

And I'm wondering if it's necessary to authenticate this token destroy action? There might be a malicious user who iterate all possible tokens(maybe!) and wrap them in a DELETE request to my server...

Thanks a lot!

Vincent Zhao
  • 167
  • 1
  • 9

5 Answers5

4

One of the aspects of restful web services is statelessness as described in the Wikipedia article.

The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all the information necessary to service the request, and session state is held in the client.

The server should not contain any information about sessions, that means, that the authentication information must be contained in each request and no login or logout methods are needed.

Best practice would be providing a resource (like some OAuth2 implementations), that returns a token with a special scope and an expiration time. At the creating process, the token should be stored in the database of the backend. After the token expires, the information must be deleted from the database and the client has to obtain a new copy of the token.

UPDATE:

@Ekkehard, that's exactly what I meant with my comment. Instead of using ‚stateful' http sessions with a session id, cookies and a session timeout, the token should be provided by an additional resource.

[...] no client context being stored on the server between requests.

If the client wants to access special services of the backend, it had to send a POST request to the token resource (where the backend stores the new token with a special expiration time in the database).

In the POST request, the client could also provide an additional query parameter scope, to create a token, that only allows you to access special parts of your backend (Google for example provides many different APIs like Google Drive, Google Mail, etc. and if the client is a mail application only access to Google Mail is necessary. It’s an additional security feature.).

The response returns the token and the client had to add this token in the header of each request to other resources.

Each request from any client contains all the information necessary to service the request, and session state is held in the client.

The tokens will be verified from the backend based on the information stored in the database.

Token resources could also provide a DELETE http method, to allow the user to delete existing tokens before the end of the expiration time. After the expiration timeout, the tokens will be automatically deleted from the database of the backend.

Patrick Leitermann
  • 2,144
  • 2
  • 13
  • 13
  • Not quite. What is meant by your quote is that the *web* service part of the server should not store any state. It is perfectly fine, and in some cases absolutely necessary to store session information on the larger "server" infrastructure (i.e., in a DB). Just not directly in the web server; especially not in persistent-between-requests web server memory. – AnoE Aug 16 '15 at 00:47
  • Hi @Ekkehard, so many thanks for your comment. And I'm just wondering about what are those **some cases**? Could you please give me a hint about when should we store session information? Actually for a server-mobile architecture, it's reasonable not to store session, just send the token to client and it will take care. But what about server-browser? – Vincent Zhao Aug 16 '15 at 07:25
  • @VincentZhao, on second reading my comment seems a bit offensive against you - I apologize for that, it was not intentional. I have encountered 2 specific reasons for tracking sessions on the server: some times the owner of the application simply wants to know when each user logged in, for how long, and under which circumstances (in those applications, the user was able to log in in different ways, getting different permissions for each session). The other reason was for the application owner to be able to forcefully terminate sessions by invalidating them in his database. – AnoE Aug 16 '15 at 16:58
  • In the first case, this surely could also simply be called "auditing"; in the second case, it made the web server do a DB roundtrip on each and every user request. Certainly that would not scale to very large applications. Nevertheless, it means session information in the DB service (not in the web server itself - which indeed I also see as a big no-no). – AnoE Aug 16 '15 at 17:02
1

If someone knows your token then they can use it to authenticate as you. In other words, by sending the token in to delete, you are authenticating yourself. No additional credentials beyond the token should be needed in a DELETE action.

There are simply too many possible tokens to iterate over for this to be a plausible attack. The attack you are worrying about is not unique to DELETE. If a user could iterate over all tokens then they would be able to impersonate any user for any action.

skyler
  • 1,487
  • 1
  • 10
  • 23
1

You can use authentication token for API. Concept is simple if your username and password matched you just create a token and send to user.

You need to set a expiration time for this token.

After expiration time or when API request for destroy you just delete this token.

Token must be send with each request.

In this approach you don't need any session.

Md Sirajus Salayhin
  • 4,974
  • 5
  • 37
  • 46
  • Many thanks for your answer, It's really clear :). However, do you think it's reasonable not to store login information on server side if the client is browser? And how could I know how many people is online now? Thank you again! – Vincent Zhao Aug 16 '15 at 07:27
  • Login information need to save on db to check valid user. If you only have aithentication for login then anyone who have the token can login. – Md Sirajus Salayhin Aug 16 '15 at 08:15
1

RESTful applications must be stateless and the security tokens need to be sent within each request using the header Authorization. Such security tokens are gotten from an authorization server using credentials or using OAuth2 authentication flow (see this link for more details http://www.bubblecode.net/en/2013/03/10/understanding-oauth2/). Such tokens have expiration dates or can be invalidated from this server.

This link could also you give more hints about the way to use tokens within RESTful applications:

Hope it helps you, Thierry

Thierry Templier
  • 198,364
  • 44
  • 396
  • 360
0

Simple answer is: YES, you need to authenticate this token destroy action

Here is three things:

  1. If username and password matches user get a token. You need to set a expiration time for this token.

  2. User must have to send token in each request. So, no session in server side is necessary.

  3. If user want to logout, destroy the token from client side, and reset token in server side. And also authenticate this token destroy action

Note: destroy the token after expiration time.

Another Note: Devise gem reset the remember_token, when we logout from web UI.

mahfuz
  • 2,728
  • 20
  • 18