Restful User/Password Authentication

Question

I'm currently designing a REST-API with the following properties:

1. Backend for a single page application (Later Apps)
2. Integrated user database for each instance
3. HTTPS/TLS only
4. Authentication with a username / password combination

My current approach for the authentication process is the following:

• (Client) POST Username&Password to /api/users/action/auth
• (Server) Authenticate User, Generate token, Send token to client
• (Client) Use Authorization-Header with token for subsequent request
• (Client) DELETE /api/users/action/auth to invalidate the token

The token will expire after some idle time.

I've chosen this design because I don't like the idea of storing the plain authentication data on the clients device.

Reading a lot of other questions and articles on this topics I don't think this approach is the best. The following questions arose:

• Does the token generation and usage for subsequent requests violate the stateless-principle of REST?
• Is this procedure secure? (XSRF?)
• Is there a better design approach? I thought OAuth may be an overkill

EDIT:

Regarding 'secure':

The application will contain a lot of sensitive information so security is quite important. Assuming the secure usage of HTTPS (only TLS, strong DH-Group, No export mods etc.) are there any easy to exploit security flaws in this approach?

Regarding 'better':

I choose this model because it's easy to implement on both sides. I put a thought into using HMAC(token, 'POST' || '/api/resource' || timeInterval) as token for each request, my conclusion was that this would add unnecessary complexity without improving security. (Already using TLS)

Answer 1

The statelessness of REST refers to the side of the server. If you pass around your token in every request this becomes part of the state that is being sent from the client and therefore does not violate the statelessness of your server.

This differs from, for example, managing state on the server where you keep information in the session server-side. A session-id sent along with the request and associated with information on the server breaks statelessness as the webserver is now maintaining a state.

As far as 'better' and 'secure' goes, there is no definitive answer to that question. The question is what degree of security you need, what you want and how far you are willing to go to implement it.

Answer 2

First of all, don't put REST above solving problems efficiently. In order for clients to be able to log in you need to somehow store some state. Whether or not you consider this to be against the REST mantra doesn't really matter, you need to do it anyway.

You could make digitally signed tokens containing all session information, and not store those on the server. But for most purposes that doesn't achieve anything practical.

I assume that you store the token in JavaScript memory on the client, send it as a special header with every request, and only return sensitive data or change data when the correct token is set in that header. In that case you should be safe from XSRF, those holes typically only arise when you use cookies.

Is there a better design? Possibly, but given your description, your's is probably good enough.