I recently had an interesting article show up in my Google newsfeed on API Keys, their generation, and their distribution. A group of developers posed the following question to the community: how do you build and distribute your API keys to your API consumer audience?
Being immersed in APIs and API developer communities every day, I was intrigued by what the various answers would be in the discussions. Not surprisingly, many developers are generating their own API keys manually using tools like OpenSSL and other methods of generating random strings which can be stored and leveraged as API keys. I worry that using these solutions draws a false equivalence between API keys and public/private keys used for PKI operations – they’re simply being used as a random string generator in these cases. Also, not surprisingly for small API operations, they are managing these keys and validations in their code.
A solid API platform should provide more than just API key validation during a transaction.
What I found to be a little bit of a concern while further reading the thread was how often I saw API keys being leveraged as a security mechanism by API providers. API keys are identifiers. When a requesting application provides their API key to an API provider, that key can be validated and cross referenced to an application that has registered to have access to the API. What it does not do is provide security. A solid API platform should provide more than just API key validation during a transaction.
The Problem with using API Keys
This is because API keys are vulnerable to attacks in various ways. They are static pieces of information that may be accessed if stored at rest, for example in a database, hard coded into an application’s programming code, written on a post-it note on someone’s monitor, etc. If an API key is built into a mobile application, for example, I can download that application from the Google Play or iPhone App Store, reverse-engineer it, and gain access to the API key. I could then use that API key to access APIs and their related information if the API key is being used as a form of security.
An API key should be used as an identifier to distinguish an application that consumes an API. It can be used as part of an OAuth flow to get valid OAuth tokens which can then be used to access an API, for example. But it should not be leveraged as the only means to secure the API. It’s too vulnerable to attack. A proper API exposure must include encryption of data in flight (TLS), validation of the API key (to identify the requesting application), and some form of end user authentication/authorization.
Security Considerations for API Keys
If you leverage OAuth flows using the resource owner credentials grant type, you can require that both an API key and secret and end user credentials are provided in order to get a valid OAuth token that can then be used to access the API. By doing something like this, even if your application is reverse-engineered and the API Key and/or Secret are compromised, it’s still only half the keys to the kingdom. Without the other half (user credentials), the attacker does not have enough information to penetrate your network and access data they should not have access to.
API keys are a common and convenient way to identify incoming applications that access your APIs. A great way to provision those keys can be to leverage an API Portal to allow consumers to get access to your APIs without having to manually generate and distribute the keys. It cuts down on manual work by the API provider, and the API consumer, by providing a quick and easy way to get each party what they need to succeed.
As the keys are identifiers that are stored at rest, either in application code or some form of database or repository, and that can be very long lived, they should not be used as the primary form of security to protect your API. They should be used as identifiers to see which applications are accessing your APIs and should be paired with other means of security in order to have a properly protected endpoint.
It should be noted that even as a means to identify applications that are leveraging your API, the key can’t really be trusted. If access to the key, even as an identifier, is compromised, I could be calling your API with a key that identifies someone else’s application and not my own, so statistics around access to the API based on the key cannot be trusted. The only way to avoid this is to use the API key as an identifier along with PKI leveraging the API secret to help with non-repudiation. And that API secret should be revocable, so that it can be replaced if compromised.
Stay safe out there, and use API keys as part of your strategy along with proper security to be successful.