Per-Request API key

Question

I've been making a standardized JSON API for my company's website; I'd like to have a way of authenticating users to use the API while keeping the API as stateless as possible. My idea was the following:

1. The user logs in, the web service authenticates the user, and generates a random string that gets passed to the client, along with an expiration date. This is stored in a cookie, as well as an entry in the database.

2. For every API request, the web service checks the cookie string against the database entry. If it authenticates, the web service will generate a new string, replace the old string with the new one in the database and the cookie, then send back the requested information.

3. If the client sends a request and the cookie does not match the database entry, the string in the database is set to NULL and the client has to log in again and start the process from step 1.

4. If a request is sent after the expiration date, the string in the database is set to NULL and the user must log in again.

I want to cause as few disruptions as possible with my company's current setup as we slowly transition to newer technology. Is this method something that is commonly done? What kind of security issues would I be running into if I do it this way? Should I be using a different method?

Answer 1

Yes, this is a common scenario. What you are describing is a session cookie and is widely used.

You might want to read into Session Fixation techniques and ways to mitigate those.

But using a session is not really stateless. If you can provide keys (shared secrets) to your API consumers, you could also consider message signing to authenticate requests. Make sure you are using (H)MAC. Also make sure that you guard yourself from Replay Attacks.