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 :
- The client first authenticates through a login form(in the client application) with his email and password.
- 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.
- The client stores the received private key and the token(in memory).
- 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.
- 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?