REST web service and API keys

Question

I have a web service that I suggest users use in my application database and receive information. Users must register for the API key and provide this when making requests. Everything works fine, but how can I check if the users who have registered for the key are really making a request, and not someone else who could give the key to?

I have been thinking over the past two days to come up with a solution, but nothing so far.

Answer 1

You need to use signed requests. It basically works like this:

• You provide your user with an API key and a “secret” (random string) that only you and the client know.
• Whenever they make a request, they add the signature parameter to it. This signature is basically a hash of the request parameters + API key + other parameters (see below) + secret.
• Since you know the secret, you can verify the signature is correct.

To avoid replay attacks, you can also add non-tags and timestamps to mixes. Nonce is simply a number that should be increased by the client for each request. When you receive a request, you check if you have already received this nonce / timestamp. If you did, you will reject the request (because it is most likely a re-attack). If not, you save nonce / timestamp in your database for later review.

This is more or less how requests are signed in OAuth . See their example in the link.

Answer 2

There are two parts to authenticating REST API calls. When a user logs in with your service, you usually assign a KEY that identifies that user. Sometimes this is enough. But this KEY can be split or stolen. In this case, your service will continue to be considered KEY valid. Now, to prevent key hijras, etc., you will also distribute the secret key. This key is never transported with a REST API request. This key is used to execute a one-way hash of the API request and create a signature (HMAC).

This signature, plus an API request (an HTTP request as a URL), is then sent to the API server. The server performs a one-way hash of the URL and compares with the signature using this user's private key. If they match, it is “assumed” that the requestor has access to the private key, and therefore the request is valid.

In order to avoid repeated attacks, in addition to nonce (as suggested by the previous poster), you can also use a hash chain.