OAuth vs API keys is not a contest between a “secure” option and an “insecure” one. They identify different things and support different authorization models. A typical API key identifies a calling project or application. OAuth can authorize limited access for a user, an organization or a workload and issue tokens with a defined scope and lifetime.
The design question is: whose authority is the client using, what may it do, and how will that authority be revoked?
Standards and documentation checked: October 18, 2026, against OAuth 2.0, the OAuth security best current practice and Google Cloud’s API-key guidance.
The short answer
Use an API key when the service mainly needs to identify the calling project for quota, billing or access to non-sensitive data, and the provider explicitly supports that model.
Use OAuth when the client needs delegated access to a user’s account, fine-grained scopes, short-lived access tokens, revocation or a workload identity that should not share one static secret.
Many production APIs use both. An API key can identify the project, while an OAuth access token identifies the principal and the permissions granted for that request. One credential does not automatically replace the other.
What an API key proves
An API key is a secret string issued by an API provider. The provider can associate it with a project, application or customer account. That makes it useful for metering, quota enforcement and basic access control.
Google Cloud’s API-key authentication guide is explicit about the boundary: a standard API key identifies the project making the call, not the user or service account acting inside that project. The related Endpoints guidance says an API key does not identify an individual user.
That difference matters. If two people and a scheduled job all share the same key, the service sees the same project credential unless the application supplies another identity layer. Audit logs cannot infer which human approved a request from the key alone.
An API key is also usually long-lived. Rotation and revocation depend on the provider. If the key leaks into a public repository, browser bundle or support ticket, anyone who possesses it may be able to use it within the key’s permissions and restrictions.
What OAuth adds
OAuth 2.0 is an authorization framework. RFC 6749 defines a way for a client to obtain limited access to an HTTP service on behalf of a resource owner or on its own behalf.
In a delegated flow, the user authenticates with the authorization server and approves access. The client receives an access token instead of the user’s password. The token can be limited by scope, resource and lifetime.
That creates controls an API key normally does not provide:
- a grant tied to a particular user or workload;
- scopes such as read-only access instead of full account access;
- access tokens that expire;
- refresh tokens that can obtain new access tokens under defined rules;
- consent and revocation at the authorization server;
- separation between the application identity and the resource owner’s authority.
OAuth does not define user authentication by itself. OpenID Connect adds an identity layer for sign-in. An application that says “Sign in with…” is often using OpenID Connect on top of OAuth, not plain OAuth as a login protocol.
Bearer tokens are still secrets
OAuth is not safe merely because it uses tokens. RFC 6750 defines bearer-token use: any party in possession of a bearer token can use it. The specification requires TLS and warns against exposing tokens in URLs, logs and other places where they can leak.
A short expiry reduces how long a stolen access token remains useful. It does not undo access already taken, and a stolen refresh token can be more durable. Store tokens with the same care as other credentials, restrict their audience and scope, and revoke them when the grant should end.
Sender-constrained token designs can add proof that the caller holds another key, but ordinary bearer tokens do not provide that by themselves.
The authorization-code flow and PKCE
For an application acting for a user, the authorization-code flow keeps the access token out of the browser redirect. The authorization server returns a short-lived code to the registered redirect URI, and the client exchanges that code at the token endpoint.
The current OAuth 2.0 security best current practice, RFC 9700, requires public clients to use Proof Key for Code Exchange, or PKCE, and recommends it for confidential clients. PKCE binds the authorization code to a verifier held by the client instance, reducing the value of a stolen or injected code.
The same document requires exact redirect-URI matching in normal cases and says public clients must use PKCE. It also advises against the implicit grant unless its token-leakage risks are specifically mitigated.
These are implementation requirements, not optional polish. A correct high-level flow can still fail through a loose redirect URI, a reusable state value, an exposed token or a missing PKCE check.
Machine-to-machine access
OAuth is not only for users clicking a consent screen. A service can use a client-credentials grant when it acts on its own behalf. The authorization server issues a token to the confidential client, usually after client authentication.
That model can be preferable to a broad API key when the provider supports scoped workload tokens, central revocation and auditable client identities. The client credential used to obtain the token is still a secret and must be stored and rotated. OAuth moves the long-lived credential away from each resource request; it does not eliminate credential management.
Cloud platforms may also support workload identity or signed assertions so a service can obtain short-lived tokens without keeping a static client secret. Use the provider’s documented flow rather than inventing a token exchange.
When an API key is enough
An API key can be a reasonable fit for:
- a public-data API that needs quota attribution;
- a server-to-server API with one narrow project identity;
- a low-risk endpoint where the provider has no delegated-user model;
- a second project-identification credential used beside a stronger principal credential.
Apply the provider’s restrictions. Google Cloud, for example, lets owners restrict a key by API and by application context such as server IP addresses, websites, Android apps or iOS apps. Restrictions reduce the blast radius but do not make a browser-exposed key suitable for privileged operations.
Keep separate keys for separate environments and applications. A production key reused in a test script creates an avoidable path from a lower-trust system into production quota or data.
When OAuth is the better fit
OAuth is usually the right choice when an application needs to:
- read or modify a user’s private account data;
- request only a subset of permissions;
- let a user revoke one application’s access without changing a password;
- identify different organizations or workloads separately;
- issue short-lived access tokens;
- support a consent or administrator-approval process;
- keep an audit trail tied to a principal rather than only a project.
The provider’s available scopes still matter. A token with one broad “full access” scope offers less control than a key protected by a very narrow endpoint policy. Evaluate the actual authorization surface, not the protocol name.
A design checklist
Before choosing a credential, write down:
- Principal: Is the caller a project, user, organization, service account or workload?
- Resource: Which API and which records may it access?
- Action: Does it need read, write, delete or administrative access?
- Lifetime: How long should one credential remain usable?
- Storage: Can the client keep a secret, or is it a public browser or mobile app?
- Revocation: Can one user’s or one workload’s access be removed independently?
- Audit: Which identity must appear in logs?
- Recovery: What happens after a credential leak?
- Rotation: Can credentials change without downtime?
- Provider rules: Which flows, scopes and restrictions does the API actually support?
For calls that create payments, orders or other mutations, authentication is only one layer. The idempotency-key guide explains how to make uncertain retries duplicate-safe. The webhooks versus polling guide covers delivery and reconciliation after authorization succeeds.
Common mistakes
Do not put a privileged API key in downloadable JavaScript and call it “restricted” without checking what the restriction actually enforces. Do not use one shared OAuth client credential as a substitute for per-user authorization. Do not log authorization headers. Do not accept arbitrary redirect URIs. Do not give every integration the widest scope because narrower scopes take more setup.
Most importantly, do not infer identity that the credential does not contain. A project key is not proof of a user. An access token is not necessarily proof of interactive sign-in. Inspect the token type, issuer, audience, scope and the provider’s validation rules.
