
I noticed that when I generate a new API key once my previous one has expired that both the old and new key have the same 107 characters. Is this by design or does it highlight a weakness in the key generation process ?

I noticed that when I generate a new API key once my previous one has expired that both the old and new key have the same 107 characters. Is this by design or does it highlight a weakness in the key generation process ?
I don't think it's an issue. Assuming the key consists of only alphanumeric characters ie. A-Z,a-z & 0-9 then the number of possible keys is 192 digits long

Realise I missed out the word first. So itโs the first 107 characters that are identical.
Have you tried generating a key with a different scope and/or expiry? Maybe those are handled in the first 107 characters
Irrespective, knowing the first 107 characters does not mean that their meaning can be established. Likewise, the entire length of the API token makes it very unlikely to be decrypted.

new API keys are slightly longer than 192 digits, like 10x longer
I don't think I explained clearly. If the key was 107 alphanumeric the number of possible combinations is approximately 6, followed by 192 zeros. ie a very large number
Given that the key is a lot longer, the number of possible combinations is exponentially larger, so having the first 107 characters the same is not really a problem.
This takes me back 40 years to the statistics and cryptography modules of my computing science degree

Are we talking API keys or API tokens? As I understand it, tokens can contain eg, specific user data, so might well have some identical strings within them... ๐

It's a fairly ubiquitous API key following the JWT (JSON Web Token) format, so follows the convention:
{header}.{payload}.{signature}
hence why the beginning sections will be mostly the same for everyone, before you start getting into the more intricate parts in the payload with things like created times & expiries etc (which should obviously change)