--- title: "Rebuttal: API keys can do everything" description: "A rebuttal to critics of API key authentication. We think that API keys are the best way to secure your API for these reasons." canonicalUrl: "https://zuplo.com/blog/2024/03/07/rebuttal-api-keys-can-do-everything" pageType: "blog" date: "2024-03-07" authors: "joel" tags: "API Key Authentication" image: "https://zuplo.com/og?text=Rebuttal:%20API%20keys%20can%20do%20everything" --- The path to creating secure APIs isn’t through obscurity. In a [recent piece](https://thenewstack.io/why-your-api-keys-are-leaving-you-vulnerable-to-attack/) on _The New Stack_, Allan Knabe argues the only way to secure APIs is a complex authentication handshake involving tokens and a hard dependency on a third-party service. With a shaky claim that API keys are inherently unable to handle both authentication and authorization, they propose passing the buck to an OAuth identity provider, ultimately giving developers a worse experience when their chief concern is making their first call as soon as possible. API keys are the only option that lets you flexibly secure your APIs in a way you own, program, and can improve at every point in the developer’s journey. So, no, API keys don’t leave you vulnerable. Instead, as we’ll learned, they will happily help you do just about everything. ## 1. Owned API keys create opportunity 🦜 _“The seemingly straightforward API key is deceptively inadequate for securing APIs that access sensitive data. The static nature of API keys … make them a liability.”_ The best security practices don’t involve deference or abstraction. They don’t involve handing the keys, for lack of a better word, to a third-party identity provider. When you [opt for API keys](/blog/you-should-be-using-api-keys) and commit to owning the security lifecycle for your API, you don’t get a static experience—far from it. You always have complete flexibility to revoke keys with a single click. Developers have the same option—with an effective developer portal, they can not only manage multiple API keys, but roll new ones quickly and leverage a rolling transition period to prevent errors or downtime for their users. A rolled/revoked key is instantly useless, unlike API tokens, which often require help from your third-party identity provider to reset an entire certificate or tenant. Only keys acknowledge this [two-way street of API security](/learning-center/api-key-authentication), where every platform you leverage and policy you instantiate must: 1. Protect your API from unauthorized access or abuse by cutting off requests in the event of a leak or intrusion. 2. Protect developers from making common mistakes in handling authentication, authorization, and data while also giving them a friction-free experience. ## 2. API keys are authorization-ready 🦜 _“API tokens serve a dual purpose, addressing core security concerns: they verify identity (authentication) and determine access levels (authorization). … Tokens can use scope so you can control the access that each integration has to your system.”_ API keys are perfectly capable of handling both authentication and authorization—as with any other security mechanism, it all hinges on how your API gateway has implemented them. There is no reason you can’t have different scopes or [access control](/learning-center/how-rbac-improves-api-permission-management) based on who generated the API key and how it’s being used in production. When you pair the flexibility of keys with an API gateway that allows for easy programmability, like Zuplo, you have far more options. Zuplo supports [custom TypeScript policies](https://zuplo.com/docs/articles/api-key-authentication#using-consumer-data-in-code), which run just after the API key authentication policy, to layer in authorization without relying on identity providers. Every request that passes through a Zuplo API gateway contains any [metadata](https://zuplo.com/docs/articles/api-key-authentication#request-user-object) you attached to the developer when they created their account _and_ the [context](https://zuplo.com/docs/articles/zuplo-context), which includes geolocation data. With these details, you can create powerful custom authorization paths that: - Limit routes to specific customer IDs using an [access control list policy](https://zuplo.com/docs/policies/acl-policy-inbound). - Create and check for user roles for [custom RBAC](https://zuplo.com/docs/policies/rbac-policy-inbound). - Respond with different subsets of API data based on the consumer’s free/starter/business/enterprise plan. - Restrict requests from certain [geographical regions](https://zuplo.com/docs/policies/geo-filter-inbound) or IP addresses for compliance. - Apply fast-running and [dynamic rate limiting](https://zuplo.com/docs/policies/rate-limit-inbound)—particularly those targeting specific API keys—to protect the availability of your API from abuse or malicious actors. With the ownership of API keys, those opportunities are as endless as your TypeScript skills and the access you must secure. ## 3. The power in embedded API keys 🦜 _“Developers often embed API keys directly into applications. This means every user operates under the same API key, with no individual authentication or authorization checks.”_ For one, API tokens operate the same when developers embed them into their apps. That’s just how machine-to-machine (M2M) works—we need authentication/authorization to be automated, which is inherently less secure than, say, requiring a new key/token for every API call. Second, an API business can control scope and access with keys, an API gateway, and some old-fashioned programming. But only with keys can developers also build systems of logical scope to protect themselves—remember, good security isn’t just about minimizing your exposure at the expense of others! Developers can: 1. Log into your developer portal and create multiple API keys. 2. Distribute those keys into their app or platform using secrets, with each API key tied to a specific action or purpose. 3. Maintain their security by revoking and rolling scoped API keys on their own schedule and for any reason. 4. Re-enable your API by updating the secret with a fresh API key. When you give developers control over how they design their systems, instead of hiding all authentication and authorization behind the brick wall of an identity provider, they’ll find creative and tangible ways to leverage the flexibility you offer into systems with fewer points of failure. ## 4. Instant mitigation for developers 🦜 _“Due to the simplicity with which API keys can be integrated, developers may become complacent, inadvertently uploading them to public repositories. The existence of tools like [git-hound](https://github.com/tillson/git-hound) is a testament to the prevalence of such slip-ups.”_ Knabe pitches the unfortunate reality of leaks as unique to API keys, but tokens are just as vulnerable. Secrets end up pushed to GitHub or caught up in a screen record. Mistakes happen. What matters is how you help developers deal with them. The existence of tools like git-hound or GitHub’s [secret scanning](https://github.blog/changelog/2022-07-13-zuplo-is-now-a-github-secret-scanning-partner/) is actually a testament to the unique flexibility of API keys. For example, Zuplo’s `zpka_` API key prefix enables [instant leak detection](https://zuplo.com/docs/articles/api-key-leak-detection) in partnership with GitHub—if you accidentally check an API key into your repository, we’ll let you know on Slack, over email, or via a webhook so you can take action. Wouldn’t you rather know about a leaked API key, versus handing over all authentication/authorization logic to a third-party identity provider you never really wanted to get into business with in the first place? For situations where leak detection can’t do the trick, you can offer [API usage analytics](/blog/analytics-for-developers-using-your-api), accessible via the consumer’s developer portal, to help them identify and understand any mis-use before revoking their keys and getting back on track. ## 5. Plus, far better developer experience 🦜 _“Why doesn’t everyone just use tokens, then? Short answer: It’s more work. … Numerous software development kits (SDKs) can simplify this process for developers.”_ Yet another hoop for developers to jump through in the name of shift-left. Even bigger bundle sizes. Another dependency to maintain as their app matures. Every solution for improving DevEx while using API tokens is still [enormously complicated](https://thenewstack.io/how-to-improve-your-oauth-developer-experience/), full of unnecessary handshakes between OAuth agents, proxies, servers, and OIDC plugins. No developer wants to manage the ClientID and secret required to generate a secure token. And you shouldn’t ask them to install an SDK in their development environment to handle token generation so they can finally integrate your API. Haven’t we learned our lessons from security practices like [forced expiry](https://www.ncsc.gov.uk/blog-post/problems-forcing-regular-password-expiry), which puts more cognitive load on the end user and ultimately results in worse security? Every step you take down the path of protecting your API through obscurity creates another point of friction, holding developers back from [sending their first call ASAP](/learning-center/optimize-ttfc-with-api-keys) so they can get back to the meaningful work: understanding the structure of your data and how to unify it with everything they’ve already built. Even a single roadblock will ensure their experience won’t be _unforgettably good_—the only real lever you have to [build a profitable API business](/learning-center/increase-revenue-by-improving-api-quality). ## Which path are you on? Keys or tokens? Ownership or obfuscation? Flexible uses or more cognitive load? We need to give up this idea that API security is something we can pass along to an identity provider or developers—that’s just trying to minimize your exposure. If you’re eager to secure your API the right way be sure to give [Zuplo](https://zuplo.com/) a try. We’d love to see how you’re using flexibility and programmability to provide a delightful and protected developer experience. Until then, one more point of contention: 🦜 _“In the digital realm, as in the physical one, the strongest lock is the one that adapts and changes, keeping unauthorized users out.”_ I’m pretty sure the strongest lock is the one where you haven’t handed over the keys to someone else.