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


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)

  • Depending on your constrain you can use client side certificate to authenticate client.
    – mathk
    Commented Aug 24, 2015 at 8:40

2 Answers 2


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.

  • What is ultimately the difference between sending a token and sending a sessionID? (Except that with a sessionID it's managed more automatically) Commented Aug 19, 2015 at 14:22
  • Could be a matter of terminology. 'Token' in this context explicitly means not bound to the server in any way, session id means the server itself stores information on the ID. Think tokens in a REST API which do not reside on the server and have to keep their timeout information embedded in themselves and PHP SessionID's which are often stored on the server that started the session and for which timeouts are stored there.
    – JDT
    Commented Aug 19, 2015 at 14:30
  • Thanks for stateless clarification. I've edited the original question regarding 'better' and 'secure'.
    – Frido
    Commented Aug 20, 2015 at 9:36

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.