Simple and secure custom API Keys using ASP.NET Core

[giscus[bot]]

Simple and secure custom API Keys using ASP.NET Core

https://www.camiloterevinto.com/post/simple-and-secure-api-keys-using-asp-net-core.html

[smurtagh]

This article was super helpful. Thank you for sharing.

[CamiloTerevinto]

I'm glad you found this useful :)

[krabobobr]

thumb up

[purplepiranha]

Whilst this has been quite useful, the code doesn't actually guarantee the key length and could fail at any time.

To demonstrate. Here is a simplified generator based on the above. Fixed to 32 bytes with no prefix.

public class KeyGenerator
{
   ...

   public string GenerateKey()
   {
       var bytes = RandomNumberGenerator.GetBytes(32);
       return Convert.ToBase64String(bytes).Replace("/", "").Replace("+", "").Replace("=", "");
   }
}

This is then called by a console app recursively:

using KeyGen;

var gen = new KeyGenerator();

int? minLength = null;
int? maxLength = null;

for (int i = 0; i < Int32.MaxValue; i++)
{
    var key = gen.GenerateKey();
    var length = key.Length;

    if (minLength is null || minLength > length)
        minLength = length;

    if (maxLength is null || maxLength < length)
        maxLength = length;
}

Console.WriteLine($"Min Length: {minLength}");
Console.WriteLine($"Max Length: {maxLength}");

After a few minutes, the following result is returned.

Min Length: 30
Max Length: 43

As you can see, at least one of the keys generated was only 30 characters long, but the examples above substring to 33 characters. This would cause an IndexOutOfRange exception.

The max length will always be 43 as the 32 bytes converted to Base64 always ends with an '=' which is removed.

The question is how do we deal with this?

We could check the length and regenerate, but if we were really unlucky it could take a few attempts before we found a valid key. This could introduce an unwanted performance overhead.

Or how about, if the length is too short, we keep the old key but add a new one to the end of it. We are more likely then to have an adequately long key on the first attempt.

Let's look at the modified code:

public class KeyGenerator
{
    public string GenerateKey()
    {
        var key = Generate32ByteBase64Key();

        while (key.Length < 33)
            key = string.Concat(key, Generate32ByteBase64Key());

        return key;
    }

    private string Generate32ByteBase64Key()
    {
        var bytes = RandomNumberGenerator.GetBytes(32);
        return Convert.ToBase64String(bytes).Replace("/", "").Replace("+", "").Replace("=", "");
    }
}

We now know that it won't return anything that's less than 33 characters long, but we'll run the console app again anyway.
This will tell hopefully give us an indication of 2 things:

1. There are no exceptions thrown.
2. A result is returned at some point - we don't want it stuck in a never ending loop.
   The results are:

Min Length: 33
Max Length: 75

Now we can add the substring and be sure that we always get 33 characters returned.

[CamiloTerevinto]

Hey @purplepiranha, thanks for the detailed comment. I actually fixed this in the NuGet package but seems like I forgot to update here as well. The following code guarantees the length:

    var bytes = RandomNumberGenerator.GetBytes(_options.LengthOfKey);

    string base64String = Convert.ToBase64String(bytes);

    if (_options.GenerateUrlSafeKeys)
    {
        base64String = base64String
            .Replace("+", "-")
            .Replace("/", "_");
    }
    
    var keyLength = _options.LengthOfKey - _options.KeyPrefix!.Length;

    return _options.KeyPrefix + base64String[..keyLength];

I ran a test from 0 to int.MaxValue and every time the length is the same.

[purplepiranha]

Hi @CamiloTerevinto, thanks for the swift response. That seems like a good option as it certainly makes it url safe and this will probably perform better than mine as well.

[CamiloTerevinto]

No worries @purplepiranha :) I've pushed an update to the post now, fixing the problem in all instances.

[nykez]

Great article! Couple questions...

I need to store API keys in the database and fetch them. Do you prefer storing the API key in the cache for X amount of time instead of hitting the db per call? Say, 5 minutes. After 5 mins a db call would be made per key

I am using identity. Is their a best approach to building a relationship between ApiKey and IdentityUser? That way we can validate and restrict access to certain route data? Such as.. we don't want customer1 accessing the api to access customer2 data and so fourth. Would this be better done with claims in the pipeline?

[CamiloTerevinto]

Hey @nykez, thanks for the kind words.

I'd say, use something like the CacheService example from the post to cache the keys in-memory for a reasonable amount of time, and 5 minutes seems like a sensible starting point.

If you are using Identity, I'd personally just add either public string ApiKey { get; set; } to your IdentityUser class. If you want to have more than one API key per user, then it would make sense to have a separate table and add a reference.