API Keys: Authenticating Machines, Not People

So far this guide has been about authenticating people — sessions, tokens, social login. But a huge amount of authentication has no human in the loop at all: one server calling another's API, a script pulling data, a service talking to a service. For this machine-to-machine case, the simplest tool is the API key. It answers a different question than everything before it: not "who is this user?" but "which application is calling?"

The idea: a secret that names an app

An API key is a long, random secret string issued to an application. The app includes it with every request, and the receiving service uses it to identify which application is calling and whether it's allowed.

Notice what's absent: there's no login screen, no user, no consent flow. A weather API gives your backend a key; your backend sends it on each call; the API recognizes your app and responds. That's the whole interaction.

Machines, not people

The defining trait is who is being authenticated. Everything earlier in this guide authenticated a user. An API key authenticates an application.

Why keys instead of OAuth here

You might ask: why not use OAuth or JWTs for machine access too? Because for pure machine-to-machine calls, those are often overkill. OAuth's whole apparatus exists to get a user's consent to delegate access — but there's no user here to consent. When it's just your own backend calling a third-party API, the elaborate flow buys you nothing.

The simplicity is the point. For "my server calls your API," sending a key is direct and sufficient. (There are richer machine-to-machine standards for stricter needs, but the humble API key covers a great deal.)

Treat it like a password

Here's where API keys bite people. An API key is a bearer secret — possession is everything. Whoever holds the key is the application, as far as the service is concerned. There's no second factor, no user behind it to challenge.

Handling keys safely

The defenses follow directly from "it's a bearer secret":

• Never expose it client-side. A key in frontend JavaScript or a mobile app is visible to anyone who looks. API keys belong on the server, supplied through environment variables and secret managers — never hardcoded or committed.
• Scope to least privilege. Following the least-privilege principle, give each key only the access it needs. A key for reading public data shouldn't be able to delete anything.
• Rate-limit per key. Because the key identifies the caller, you can cap how much each one may do — protecting you from both abuse and a runaway buggy client.
• Rotate regularly. Periodically issuing new keys and retiring old ones means a leaked key is only useful for a limited window. Build for rotation from the start, so swapping a key isn't a crisis.

These practices share one goal: shrink the blast radius if a key ever leaks — limit what it can do, how much, and for how long.

Recap

• An API key is a secret string that identifies and authenticates an application, not a user.
• It's the simple choice for machine-to-machine access, where OAuth's user-consent machinery is overkill.
• It's a bearer secret — anyone holding it can act as that app, so a leak is as serious as a leaked password.
• Never expose keys client-side or in repos; keep them in server-side secrets.
• Scope, rate-limit, and rotate keys to shrink the blast radius of any leak.

API keys identify which app is calling. Once you know who (or what) is calling, you decide what they can do — and the standard model for that is roles. Continue to Role-Based Access Control (RBAC).