API key, explained
The provider issues a key, and the client sends it with every request, most often in a header such as Authorization: Bearer sk_live_... or X-API-Key. The server looks up the key to identify the account, apply rate limits and permissions, and attribute usage for billing.
API keys are simple, which is their strength and their weakness. A key usually identifies a project rather than a user, does not expire on its own and grants whatever it is scoped to until someone revokes it. Anyone who copies it can use it, so a key committed to a public repository or shipped in a mobile app is effectively public.
- Send keys only over HTTPS and only in headers, never in URLs, where they end up in logs.
- Use separate keys per environment (test and live) and per integration, with the narrowest scopes available.
- Store keys in a secrets manager, rotate them regularly, and revoke them immediately if exposed.
For acting on behalf of users or granting fine-grained, expiring access, OAuth 2.0 is the better fit.
Related terms
- OAuth 2.0: OAuth 2.0 (RFC 6749) is an authorization framework that lets an app get limited, revocable access to an API on a user's behalf without their password.
- API security: API security is the practice of protecting APIs from misuse and attack with authentication, authorization, input validation, rate limits and monitoring.
- Rate limiting: Rate limiting caps how many requests a client can make to an API in a given time window, protecting the service from overload and abuse.
- JSON Web Token (JWT): A JSON Web Token (JWT, RFC 7519) is a compact, URL-safe token of signed JSON claims, widely used as an access or ID token to authenticate API calls.