Just about every API will allow for API Keys. Not everything authenticating to an API is going to be a user. So having a good plan is key (heh, see what I did there). Let me describe the enticing and wrong way to implement API KEYs that I learned from experience.

The Bad

This can also be read as “The Easy”. A lot of times we are rushed, as engineers, to get something that meets the minimal requirements and the easy way is sure easy. It can be summed up as:

• A single API Key that is basically a password replacement
• Resettable

Why is this wrong? Here’s a list:

• Resetting the API Key cannot be done without downtime
• API Key cannot be used with permissions other than that of the user

The Good

• User is able to generate as many keys as they want
• User is able to apply as few or many permissions (that they have access to) to the API Key

This way a user who wants to rotate an API Key can generate a new key, rotate their integration API Key, then deactivate their old API Key.

Allowing for users to specify permissions also protects them from potentially malicious 3rd Party apps as it limits the amount of damage that can be done if misused.

This may seem like “common sense” but when you’re rolling at a million miles an hour, this can be something overlooked until you slow down and look back.