Why-API-Keys-are-Not-Enough-Nordic-APIsWe’re all accustomed to using usernames and passwords for hundreds of online accounts — but if not managed correctly, using passwords can become a major distraction, and a potential security vulnerability. The same is true in the API space. There’s nothing inherently wrong with usernames — you need those. But if you use them without also having some sort of credential that allows the service to verify the caller’s identity, you are certainly doing it wrong.

Unfortunately, many API providers make a dangerous mistake that exposes a large amount of data and makes an entire ecosystem insecure. In plain English — if you’re only using API keys, you may be doing it wrong!

What is an API Key?

An API Key is a piece of code assigned to a specific program, developer, or user that is used whenever that entity makes a call to an API. This Key is typically a long string of generated characters which follow a set of generation rules specified by the authority that creates them:

Upon account creation or app registration, many API providers assign API keys to their developers, allowing them to function in a way similar to an account username and password. API keys are unique, and because of this, many providers have opted to use these keys as a type of security layer, barring entry and further rights to anyone unable to provide the key for the service being requested.

Despite the alluring simplicity and ease of utilizing API Keys in this method, the shifting of security responsibility, lack of granular control, and misunderstanding of purpose and use amongst most developers makes solely relying on API Keys a poor decision. More than just protecting API keys, we need to program robust identity control and access management features to safeguard the entire API platform.

Shifting of Responsibility

In most common implementations of the API Key process, the security of the system as a whole is entirely dependent on the ability of the developer consumer to protect their API keys and maintain security. However, this isn’t always stable. Take Andrew Hoffman’s $2375 Amazon EC2 Mistake that involved a fluke API key push to GitHub. As developers rely on cloud-based development tools, the accidental or malicious public exposure of API keys can be a real concern.

From the moment a key is generated, it is passed through the network to the user over a connection with limited encryption and security options. Once the user receives the key, which in many common implementations is provided in plain text, the user must then save the key using a password manager, write it down, or save it to a file on the desktop. Another common method for API Key storage is device storage, which takes the generated key and saves it to the device on which it was requested.

When a key is used, the API provider must rely on the developer to encrypt their traffic, secure their network, and uphold their side of the security bargain. There are many vulnerabilities at stake here: applications that contain keys can be decompiled to extract keys, or deobfuscated from on-device storage, plaintext files can be stolen for unapproved use, and password managers are susceptible to security risks as with any application.

Due to its relative simplicity, most common implementations of the API Key method provide a sense of false security. Developers embed the keys in Github pushes, utilize them in third-party API calls, or even share them between various services, each with their own security caveats. In such a vulnerable situation, security is a huge issue, but it’s one that isn’t really brought up with API Keys because “they’re so simple — and the user will keep them secure!”

This is a reckless viewpoint. API Keys are only secure when used with SSL, which isn’t even a requirement in the basic implementation of the methodology. Other systems, such as OAuth 2, Amazon Auth, and more, require the use of SSL for this very reason. Shifting the responsibility from the service provider to the developer consumer is also a negligent decision from a UX perspective.

Watch Travis Spencer give a session on the Nuts and Bolts of API Security

Lack of Granular Control

Some people forgive the lack of security. After all, it’s on the developer to make sure solutions like SSL are implemented. However, even if you do assure security, your issues don’t stop there — API Keys by design lack granular control.

Somewhat ironically, before API keys were used with RESTful services, we had WS-Security tokens for SOAP services that let us perform many things with more fine-grained control. While other solutions can be scoped, audienced, controlled, and managed down to the smallest of minutia, API Keys, more often than not, only provide access until revoked. They can’t be specifically controlled dynamically.

That’s not to say API Keys lack any control — relatively useful read/write/readwrite control is definitely possible in an API Key application. However, the needs of the average API developer often warrant more full-fledged options.

This is not a localized issue either. As more and more devices are integrated into the Internet of Things, this control will become more important than ever before, magnifying the choices made in the early stages of development to gargantuan proportions later on in the API Lifecycle.

Square Peg in a Round Hole

All of this comes down to a single fact: API Keys were never meant to be used as a security feature. Most developers utilize API Keys as a method of authentication or authorization, but the API Key was only ever meant to serve as identification.

API Keys are best for two things: identification and analytics. While analytic tracking (and specifically API Metrics) can make or break a system, other solutions implement this feature in a more feature-rich way. Likewise, while API Keys do a great job identifying a user, other alternatives, such as public key encryption, HoK Tokens, etc. do a much better job of it while providing more security.

The Pros of API Keys

There are definitely some valid reasons for using API Keys. First and foremost, API Keys are simple. The use of a single identifier is simple, and for some use cases, the best solution. For instance, if an API is limited specifically in functionality where “read” is the only possible command, an API Key can be an adequate solution. Without the need to edit, modify, or delete, security is a lower concern.

Secondly, API Keys can help reduce the entropy-related issues within an authenticated service. Entropy — the amount of energy or potential within a system constantly expended during its use — dictates that there are a limited amount of authentication pairs. If entropy dictates that you can only have 6.5 million unique pairs when limited within a certain character set and style, then you can only have 6.5 million devices, users, or accounts before you run into an issue with naming. Conversely, establishing an API Key with a high number of acceptable variables largely solves this, increasing theoretical entropy to a much higher level.

Finally, autonomy within an API Key system is extremely high. Because an API Key is independent of a naming server and master credentials, they can be created autonomously. While this comes with the caveat of possible Denial of Service attacks, the autonomy created is wonderful for systems that are designed to harness it.

When developing an API, a principle of least privilege should be adhered to — allow only those who require resources to access those specific resources. This principle hinges on the concept of CIA in system security — Confidentiality, Integrity, and Availability. If your API does not deal with confidential information (for instance, an API that serves stock exchange tickers), does not serve private or mission-critical information (such as a news/RSS API), or demand constant availability (in other words, can function intermittently), then API Keys may be sufficient.

Additionally, API Keys are a good choice for developer-specific API uses. When developers are configuring API clients at operation time, and use changing keys for different services, this is acceptable.

Back to Reality

The benefits of using API Keys outlined above are still tenuous in the general use-case scenario. While API keys are simple, the limitation of “read-only” is hampering rather than liberating. Even though they provide for higher levels of entropy, this solution is not limited to API Keys and is inherent in other authentication/authorization solutions as well. Likewise, autonomy can be put in place through innovative server management and modern delegation systems.

Conclusion: API Keys Are Not a Complete Solution

The huge problems with API Keys come when end users, not developers, start making API calls with these Keys, which more often than not expose your API to security and management risks. What it comes down to is that API Keys are, by nature, not a complete solution. While they may be perfectly fine for read-only purposes, they are too weak a solution to match the complexity of a high-use API system. Whenever you start integrating other functionality such as writing, modification, deletion, and more, you necessarily enter the realm of Identification, Authentication, and Authorization.

Basic API Key implementation doesn’t support authentication without additional code or services, it doesn’t support authentication without a matching third-party system or secondary application, and it doesn’t support authorization without some serious “hacks” to extend use beyond what they were originally intended for.

While an argument could be made for expanding out the API Keys method to better support these solutions, that argument would advocate re-inventing the wheel. There are already so many improved solutions available that adding functionality to an API Key system doesn’t make sense. Even if you did add something like authentication, especially federated authentication, to the system using Shibboleth, OpenID, etc., there are a ton of systems out there that already have support for this.

More on API Security from the Nordic APIs team:


API Keys ≠ Security. Check out “Securing the API Stronghold” for more.

One of the most important facets of API development is the creation of a complete, effective security solution. Deciding on the techniques and methods used to secure your information is by far the most important step in the API development lifecycle as a single misstep in this area can lead to devastating security holes.

We write about API security often — it’s not as dry as it seems! Check out the following articles for more expert advice, or download our comprehensive guide to API security: Securing the API Stronghold.

About Kristopher Sandoval

Kristopher Sandoval is a web developer, author, and artist based out of Northern California with over six years of experience in Information Technology and Network Administration. He writes for Nordic APIs and blogs on his site, A New Sincerity.

  • Mike Schwartz

    Excellent blog… if developers did the simple “wash your hands” security requirements, the Internet would be a lot safer. I think “don’t rely on API keys” falls into the category. Its true that OpenID Connect provides for crypto client authentication, but what if you are using the plain OAuth2 client credential grant? We just added this feature for Gluu Server version 2.4.1, which should be available soon.

  • Interesting blog article. Yes I see there also the problem posting or pushing API token e.g. to public code repos like Github. And it’s not really easy to remove them with git.
    From my point as developer, an API token is a different type of private (SSH) key. And every developer should handle the API token like his private SSH key. First move the API token from the project into your (secured) home folder on your encrypted drive.