How does Algolia's virtual API keys work?

Question

Algolia allows you to generate virtual/secured API keys from another parent API key but without a call to their servers.

A virtual key thus generated on the server side with a defined "scope" (like a pre-defined user filter), can be exposed on the JS client and guarantees that API calls made using that virtual key are restricted to the scope defined when the virtual key was generated. It's easy to create 1 virtual key for every user without making requests to Algolia and ensures that each key is unique to a user.

Here's the Python implementation. I see that they are essentially creating HMAC hash with the parent key and pre-defined query parameters (the scope), and then base64 encoding it again with the raw query parameter string.

What I don't understand

When an API call is made using this virtual key, how will Algolia be able to verify that the request is valid? Are they going to iterate all existing API keys, regenerate the same HMAC+base64 string and compare with the key sent?

Is there a better way to achieve this?

Answer 1

I think the trick here is that your application is referred to a small count of keys, therefore the server will quickly iterate over all keys, also server may store some cache of such computations, because random nonce is not used in the algorithm.

Let's see the way to initialize the Algolia search client:

client = SearchClient.create('YourApplicationID', 'YourAPIKey')

Their algorithm to generate a "secured API key" from the "parent key" is the following:

securedApiKey = BASE64(HMAC[parentApiKey + query params] + query params)

Note, that query params are concatenated to HMAC value as a plaintext. So the algorithm on the server side most probably looks like this:

1. Step 1: Select keys of 'YourApplicationID' only as "parent keys".
2. Step 2: retrieve HMAC and query parameters from BASE64 of securedApiKey.
3. Step 3: HMAC(adminApiKey, query params) == secureApiKey's HMAC?
4. Step 4: HMAC(searchApiKey, query params) == secureApiKey's HMAC?
5. Step 5: Try another key.
6. Step 6: Select the proper key, or else - error.

Once the proper parent key is found, HMAC is calculated, this information could be stored, so the next request is narrowed down to a memcmp instead of HMAC * count of keys.

I don't see another way to correlate different keys in this scheme. Please, correct me, if I'm missing something.