OAuth vs API Key
Delegated authorization vs simple credentials — understanding when each mechanism is the right choice.
For a broader overview of all API authentication options, see the API Authentication Methods guide.
Use API keys for server-to-server calls, internal services, and simple integrations where you control both ends. Use OAuth 2.0 when your application needs to act on behalf of a user, access third-party resources, or delegate scoped permissions without sharing credentials.
- →API key: simplest credential model, instant revocation, no user involvement.
- →OAuth: designed for third-party authorization, user consent flows, and scoped access.
- →OAuth adds significant complexity — only adopt it when the use case requires it.
- •Your server calls another server — no user in the flow
- •You need instant key revocation with zero infrastructure
- •You're building an internal service or single-tenant integration
- •Complexity budget is low and simplicity wins
- •The callers are developers who manage their own keys
- •Your app needs to act on behalf of a user
- •You're integrating with a third-party service on a user's behalf
- •You need scoped, time-limited permissions the user can revoke
- •You're building a public API that third-party developers will integrate
- •Compliance requires user consent and auditability
Core Comparison
| Aspect | API Key | OAuth 2.0 |
|---|---|---|
| Designed for third-party apps? | No — credential belongs to the caller | Yes — core purpose |
| User-level authorization? | No — identifies application, not user | Yes — acts on behalf of an authenticated user |
| Token expiration? | Manual (no built-in expiry) | Built-in — short-lived access token + refresh token |
| Revocation? | Instant — delete from DB | Via token introspection endpoint or blocklist |
| Complexity? | Low — generate, store, validate | High — authorization server, flows, refresh tokens |
| Suitable for internal services? | Yes — common pattern | Over-engineered unless already using OAuth for users |
| Recommended for public APIs? | Yes, for M2M / developer integrations | Yes, when user data access is required |
How API Keys Work
An API key is a long random string — typically 128–256 bits of entropy — generated by the server and issued to a client. When the client makes a request, it includes the key in the Authorization: Bearer header (or occasionally a custom header). The server looks up the key in its database, identifies the caller, checks permissions, and applies rate limits.
API keys are opaque — they carry no information themselves. Everything the server needs to know about the caller (identity, scopes, status) lives in the database record. Revocation is instant: mark the key inactive and the next request fails.
The primary weakness is that they have no built-in notion of a user, no expiry, and no scope — the key either has access or it doesn't. For machine-to-machine communication and developer integrations, these are acceptable trade-offs.
Security note: store hashed keys
Store SHA-256 hashes of API keys in the database, not the raw keys. If your database is breached, hashed keys can't be used directly. Show the full key only once at creation time — this is the model used by Stripe, GitHub, and most well-designed API platforms. See the API Key vs JWT comparison for more details.
How OAuth 2.0 Works
OAuth 2.0 is an authorization framework — not an authentication protocol — that allows an application (the client) to obtain limited access to a resource server on behalf of a resource owner (the user), without the user sharing their credentials with the client.
- 1The client redirects the user to the authorization server's login page.
- 2The user authenticates and consents to the requested scopes (e.g., read:email, write:calendar).
- 3The authorization server redirects back to the client with a short-lived authorization code.
- 4The client exchanges the authorization code for an access token (and refresh token) by calling the token endpoint server-to-server.
- 5The client uses the access token to call the resource server API on behalf of the user.
- 6When the access token expires, the client uses the refresh token to obtain a new access token without re-involving the user.
OAuth ≠ Authentication
OAuth 2.0 authorizes access to resources; it does not define how to authenticate users. OpenID Connect (OIDC) is the identity layer built on top of OAuth 2.0 — it adds a standardized ID token (a JWT) that contains user identity claims. When you "Sign in with Google", the product is OIDC, not bare OAuth.
When API Keys Are Sufficient
Server-to-Server Integrations
Your backend calling Stripe, Twilio, or SendGrid is the canonical API key use case. There is no user — just your application server accessing a service API. API keys are simpler, easier to rotate, and universally supported.
Internal Microservices
Service A calling Service B within your own infrastructure. The services are in a trusted network, no user delegation is needed, and the complexity of an OAuth authorization server is not justified. A shared secret (API key or mutual TLS) is appropriate.
Developer-Facing Public APIs
Developer platforms like OpenAI, GitHub (for read-only access), and many SaaS products issue API keys that developers use directly. The developer, not an end user, is the identity. Keys are created in a dashboard, scoped by the developer, and rotated as needed.
When OAuth Is Necessary
Acting on Behalf of a User
If your application needs to read a user's Google Calendar, post to their Twitter account, or access their Dropbox files, you must use OAuth. The user must explicitly grant consent for each scope. Sharing the user's credentials with your application (password anti-pattern) is exactly what OAuth was designed to prevent.
Third-Party Application Ecosystem
If you're building a platform and want third-party developers to build apps that access your users' data — like Slack's app marketplace or Shopify's partner integrations — OAuth is the standard mechanism. It gives users visibility into which apps have access and the ability to revoke them individually.
Scoped, Revocable Delegated Access
When you need fine-grained permission scopes ("read-only access to orders" vs. "full account access") that users can grant and revoke through an interface, OAuth's authorization model is the right fit. API keys are binary — they either work or they don't.
Migration Considerations
Migrating from API keys to OAuth is a significant architectural change. Consider these factors before committing:
You need an authorization server
OAuth requires a dedicated authorization server (AS). You can build your own (complex) or use a managed service (Auth0, Okta, AWS Cognito, Keycloak). Budget for setup, maintenance, and the learning curve.
Client changes are required
Existing API clients built against a key-based API must be updated to handle the OAuth flow — redirect-based authorization, token refresh, and secure token storage. This is a breaking change if you don't maintain backwards compatibility.
Support both during transition
Running API keys alongside OAuth tokens during migration is common. Your auth middleware checks the credential type: if it looks like a JWT, verify the signature; if it's a random string, look it up as an API key. Deprecate keys gradually with a sunset deadline.
Consider OAuth only for user-delegated flows
If your use case is M2M (no user), consider OAuth's Client Credentials grant — it's essentially a structured API key mechanism with token rotation. However, simple API keys are often just as appropriate and far simpler to manage.
Common Mistakes
Using OAuth for simple M2M when API keys suffice
OAuth Client Credentials is sometimes used for machine-to-machine calls that would be simpler with a plain API key. If there is no user in the flow and no need for scoped delegation, the overhead of an authorization server is rarely justified.
Storing OAuth access tokens like long-lived API keys
Access tokens are designed to be short-lived (minutes to hours). Storing them in a database and reusing them indefinitely defeats their purpose. Implement the refresh token flow properly to keep access tokens short-lived.
Treating OAuth as an authentication protocol
OAuth says "this app can access X resource on behalf of this user." It does not say "this user is who they claim to be." For authentication, use OpenID Connect (OIDC), which adds identity assertions on top of OAuth.
Requesting overly broad scopes
Requesting full access when you only need read access violates the principle of least privilege and reduces user trust. Define fine-grained scopes and request only what your application needs at the time it needs it.