REST API。我需要对注销动作进行认证吗？[英] REST API: Do I need to authenticate log out action?

问题描述

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!

推荐答案

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.

其他推荐答案

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.

其他推荐答案

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.