API Key Authentication

What is API key authentication?

API key authentication uses a single secret string — the API key — to identify and authorize the application or project making calls to an API. The caller includes the key with each request (ideally in a header like Authorization or X-API-Key), and the API checks it against its records to decide whether to allow the call and which account to attribute it to. It’s the simplest common API auth mechanism, which is exactly why it’s everywhere (weather APIs, payment SDKs, LLM provider APIs) — and why it’s frequently used for jobs it’s poorly suited to.

What it is good at — and what it is not

The right mental model: an API key answers “which application is this?”, not “which user is this, and what may they do?” It’s application-level identification, well suited to server-to-server calls where a backend authenticates itself to a third-party API. Where it falls short is user authentication and fine-grained authorization. A raw API key typically carries no user identity and no granular permissions — it’s a coarse, all-or-mostly-nothing credential. For user login you want OIDC; for delegated, scoped, expiring access you want OAuth 2.0 access tokens (JWTs) with defined scopes. Reaching for a bare API key to do user auth or delegated authorization is a classic misuse that leads to over-privileged, un-scoped access. The honest positioning: API keys are fine for identifying an app and gating access to an API; they are not a substitute for proper authentication and authorization frameworks when users and permissions are involved.

The security realities

API keys are long-lived shared secrets, and that shapes every risk. The dominant failure mode is leakage: keys hardcoded in source code and pushed to public repos, embedded in client-side/mobile apps where anyone can extract them, exposed in logs, or pasted into config that leaks — automated scanners crawl GitHub for exposed keys within minutes. Because a leaked key is often a valid credential until someone notices, the damage window can be large (and, with paid APIs like LLM providers, expensive — a leaked key can rack up real charges fast). Mitigations that matter: never embed keys in client-side code, keep them server-side and in secret managers; scope and restrict keys (by IP, referrer, or allowed operations) to limit blast radius; transmit only over TLS and in headers, never in URLs (URLs land in logs and history); pair with rate limiting to cap abuse; and rotate keys periodically and immediately on suspected exposure. Treat an API key like a password, because that’s what it is.

What people get wrong

• Embedding keys in client-side or mobile apps — anyone can extract them; keys belong on the server, behind a backend you control.
• Using API keys for user auth/authorization: they identify an app, not a user, and lack scopes — use OIDC/OAuth for users and permissions.
• Keys in URLs or logs, and never rotating — URLs and logs leak; long-lived un-rotated keys turn a single exposure into lasting, sometimes costly, access.

Primary source: OWASP API Security Top 10