I have to implement a token based authentication for a RESTful web service. This is the first time I'm implementing security features in a software, and this is what I have in mind for now :

  1. The client first authenticates through a login form(in the client application) with his email and password.
  2. If the authentication succeeds, the user will get in a response a private key(randomly generated) and a token(string - randomly generated ?). The server will store in the db(or maybe a cache ?) a tuple with the following fields (email, private key, hashedToken, token expiration), where hashedToken is the value of the HMAC computed over the token, keyed with the private key.
  3. The client stores the received private key and the token(in memory).
  4. For every future request, the client will include in a custom header (i.e. authToken) the value of the HMAC computed over the token, keyed with the private key and the user's email(in another header) and will replace the token stored in memory with the newly generated token.
  5. When the server receives the request, it checks for the tuple mathcing the email address, checks if the stored token and the received token are equal and if the token hasn't expired. If it's ok, the server updates the tuple expiration date and the hashedToken field is set to the value of HMAC computed over the old token, keyed with the private key. the server then processes the request.(no additional authentication headers or info included in the response)

Steps 1 and 2 will use HTTPS. Other requests will be sent by HTTP, since a new token is generated after each succesful request(sniffing the token would be useless for an attacker, I think).

I would like to know what are the the problems with this authentication protocol and how it could be improved.

Also, would this approach be faster than just including the email and password in a header in each request and using HTTPS?

  • Not getting into the answer yet, but once you start with a login form, it's not really a RESTful web service anymore... In fact, in many cases clients wouldn't be able to consume it properly....
    – AviD
    Commented Aug 26, 2013 at 12:10
  • the login form is in a different application(a web or mobile app). it sends to the server a post request over https with the email and password as parameters. Commented Aug 26, 2013 at 13:40
  • Sure, but can you complete an entire session over the REST API? If not, the web service is unusable from e.g. a non-interactive (or non-UI) client application. It just seems like you're mixing the components here.
    – AviD
    Commented Aug 26, 2013 at 19:38

2 Answers 2


The basic answer is: just use HTTPS, and basic authentication. This is much simpler. The overhead of HTTPS is slight:

  • A couple of extra roundtrips when a new connection is established. But connections are kept alive between client and server, and closed only when unused for too much time, so this should not matter much. Indeed, a pure-HTTPS solution could be faster than your HTTPS/HTTP mix because it could work over a single connection for the whole procedure.

  • Some network overhead, about 0.2% for bulk data (SSL record header and padding and MAC); again, this will hardly show up on measures, let alone matter.

  • Some CPU overhead, but much less than usually assumed. A basic CPU core can encrypt and decrypt data at more than 100 MB/s, even without using AES-NI.

If you do want to use HTTP (after an initial HTTPS phase), then you must account for confidentiality and integrity issues. Your HMAC games may help with integrity, but will prevent replay attacks only as long as the server remembers the last "token value" (or hash thereof). This is state and contradicts the point of REST.

  • The biggest drawback of using HTTP basic authentication is its inability to log out. There are some hacks that work for some browsers and don't for others but that authentication method per se does not provide such capability.
    – Alex K
    Commented May 29, 2015 at 10:45

This approach is vulnerable to Man In The Middle attackers.

An attacker will let succeed the HTTPS initial phase, then every request intercepted by the attacker could steal a valid token if the request is not forwarded to the legitimate server.

You should use the content of the REST request when you calculate the HMAC in order to avoid giving unrestricted token to the attacker.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .