OAuth 2.0 vs API Key
API keys and OAuth 2.0 solve different problems despite often being compared as API authentication alternatives. API keys are long-lived static secrets, typically 32–64 random bytes encoded as hex or Base64. They identify and authenticate a specific caller (a service, a developer account, or an application). The server stores the key hash, and any request bearing the key is trusted as coming from that caller. API keys are simple: one header, no flows, no token exchange. OAuth 2.0 is a delegation framework. It allows a user to grant a third-party application limited access to their resources without sharing their credentials. The application receives an access token with specific scopes, a short expiry, and an issuer – not a long-lived secret. The token can be verified offline (JWT) or via introspection (RFC 7662), and it expires automatically. The core difference: API keys authenticate identity ('this is Stripe's API, request #12345'). OAuth 2.0 tokens authorize actions ('this token can read:orders for user alice, expires in 1 hour'). Many public APIs use both simultaneously: an API key identifies the developer/application at the infrastructure level (rate limiting, billing attribution), while OAuth 2.0 tokens carry the per-user authorization context for user-specific operations.
API keys are static secrets that identify and authenticate a caller. OAuth 2.0 is a delegation framework that issues scoped, short-lived tokens allowing a third party to act on behalf of a user. API keys are simple and suitable for server-to-server machine identity. OAuth 2.0 is required when an application needs to act on behalf of a user or when fine-grained scope control and token revocation matter. Most public APIs use both: API keys for direct server access, OAuth 2.0 for user-delegated access.
| Feature | OAuth 2.0 | API Key |
|---|---|---|
| Purpose | Delegated authorization with scopes and expiry | Identity + authentication of a caller |
| Lifetime | Short-lived access tokens (15min–1hr) + refresh | Long-lived, often permanent until revoked |
| Revocation | Instant – revoke at authorization server | Instant – delete from API key store |
| Scopes | Granular per-token scopes (read:orders, etc.) | No built-in scopes – binary allow/deny |
| User delegation | Yes – user grants app permission via consent flow | No – key is tied to application, not a user |
| Implementation | Complex – authorization server, flows, token refresh | Simple – generate, store hash, check on request |
| Standard | RFC 6749, RFC 7636 (PKCE), RFC 6750 (Bearer) | No RFC – de facto convention (X-API-Key or Authorization: ApiKey) |
| Rotation | Access tokens auto-expire; refresh tokens rotate | Manual rotation – must invalidate old, distribute new |
| Multi-tenant | Each user gets their own token with their scopes | One key per application or developer account |
| Audit logging | Token carries iss, sub, jti for full attribution | Key identifies application but not individual users |
| Secret exposure risk | Short-lived tokens limit blast radius | Long-lived key exposure requires immediate rotation |
| Transport | Authorization: Bearer <token> | X-API-Key: <key> or Authorization: ApiKey <key> |
When to use OAuth 2.0
OAuth 2.0 is the right choice when: a third-party application needs to act on behalf of a user (social login, accessing user's calendar, reading their repos), when fine-grained per-token scope control matters, when automatic token expiry is needed to limit breach impact, and when you need to support user revocation (users can revoke an app's access). OAuth 2.0 is mandatory for any public-facing authorization flow involving user data.
When to use API Key
API keys are the right choice for: server-to-server machine identity where there is no user context (CI/CD pipeline calling an API, backend service calling a data provider), simple developer APIs where ease of use matters more than granular control, billing and rate limiting attribution, and internal microservice authentication on trusted networks. Most SaaS APIs (Stripe, Twilio, SendGrid) use API keys for their primary developer integration.
Common Mistakes
- Storing API keys in source code or version control – API keys committed to git are frequently scraped by automated scanners within minutes. Always use environment variables or a secrets manager (AWS Secrets Manager, HashiCorp Vault).
- Using a single API key for all environments – use separate keys for development, staging, and production. Limit production key access to production infrastructure only.
- Choosing OAuth 2.0 when you don't need user delegation – OAuth 2.0 Client Credentials grant is equivalent to an API key for machine-to-machine use, but adds complexity without meaningful benefit over a well-managed API key. Use Client Credentials if you want JWT-format tokens with expiry; use API keys if simplicity is priority.
- Not hashing API keys at rest – store the SHA-256 hash of the API key, not the plaintext key itself. This way, a database breach does not immediately expose all API keys.
FAQ
Can I use OAuth 2.0 Client Credentials instead of an API key?
Yes. OAuth 2.0 Client Credentials grant (RFC 6749 §4.4) is functionally equivalent to an API key for machine-to-machine scenarios – the application authenticates with client_id and client_secret to get a short-lived access token. The advantage over a raw API key: tokens expire automatically, limiting breach impact. The disadvantage: you need an authorization server infrastructure.
Do I need both an API key and OAuth 2.0?
Many APIs use both for different purposes. The API key identifies the application at the infrastructure level (billing, rate limiting) and remains constant. OAuth 2.0 tokens carry per-user authorization context and expire. Stripe, GitHub, and Salesforce all use this pattern.