An API key is a credential that an application presents to an API. OAuth 2.0 is an authorization framework through which an application obtains tokens granting access to resources. The choice affects who can connect an integration, which permissions it receives and how access ends. Both approaches require controls for credentials and permissions; the provider’s implementation determines what those controls can do.
For a Product Manager, the useful starting point is the integration being planned. A customer exporting orders into its own reporting system has different requirements from a marketplace application connecting to hundreds of customer accounts. The authentication and authorization model will shape onboarding, support and the consequences of a compromised credential.
What an API key allows depends on the service
A private API key is usually a string generated by a provider and stored by the application calling its API. The service checks the key when a request arrives and applies the access rules associated with it. Depending on the provider, a key may identify a project, an application or an account. It does not necessarily identify the person operating that application.
Keys can have meaningful restrictions. A provider may allow a key to read orders while preventing refunds, restrict requests to particular network addresses or let administrators create a separate key for each integration. These capabilities need to be checked in the documentation. Stripe, for example, provides restricted keys with resource-specific permissions. A key from another service may offer much broader access.
This article focuses on private keys used for backend integrations. Some services also issue publishable keys intended for browser or mobile code; those have a different role and must not be treated as a substitute for a private credential. A secret key embedded in a downloadable application or public repository can be extracted and used outside the intended integration.
How OAuth changes the connection
In a user-delegated OAuth connection, an application requests access to resources held by another service. The user signs in with that service and authorizes the requested access, subject to the provider’s rules. The application then receives an access token to call the API without collecting the user’s password. A calendar integration, for example, might request permission to read events without being able to change them.
Those permissions are commonly expressed as scopes. Their granularity depends on the API: a scope might cover a narrow operation or a broad set of data. An access token has a limited lifetime, and some flows also issue a refresh token that the application can exchange for new access tokens. Renewal may happen in the background, but revoked permissions or an expired refresh token can require the user to reconnect. Google documents these behaviours for its APIs.
OAuth also supports communication between systems without an interactive user approval screen. In the client credentials flow, a confidential application obtains a token for access on its own behalf. Engineering may therefore propose OAuth for a background B2B process. The relevant distinction is whose authority the integration uses, rather than whether someone clicks “Connect”.
OAuth concerns authorization. A product that also needs to establish a user’s identity for sign-in will commonly use OpenID Connect, an identity layer built on OAuth 2.0. This distinction matters when defining whether a connection grants access to data, signs someone into the product or does both.
API keys vs. OAuth: permissions and lifecycle
| Decision | API key | OAuth 2.0 |
|---|---|---|
| Who is represented? | An application, project or account, depending on the provider. | An application acting on its own behalf or with delegated access. |
| How are permissions limited? | Restrictions or roles attached to the key, if supported. | Scopes and authorization policies supported by the service. |
| How does access start? | An administrator typically generates and configures a credential. | The application obtains tokens through the appropriate flow; delegated access may involve user or administrator approval. |
| What expires? | The key may remain valid until revoked, or expire under the provider’s policy. | Access tokens expire; renewal and refresh-token lifetime depend on the flow and provider. |
| How does access end? | Disable or delete the relevant key and verify enforcement. | Revoke the relevant grant or tokens and check when issued access tokens stop working. |
| What must be operated? | Secure storage, rotation, access restrictions and usage monitoring. | Token storage and renewal, authorization flows, revocation and any client credentials the application uses. |
The comparison needs to be made against the actual provider. An API key with narrow permissions and reliable rotation can be appropriate for a controlled process. An OAuth integration with excessive scopes or poorly protected refresh tokens can still expose sensitive data. Short-lived access tokens limit one part of that exposure; the credentials used to obtain new tokens need protection too.
Two B2B integrations with different requirements
Consider a hypothetical commerce platform, Mercato. A customer wants to copy its orders into an internal reporting tool each night. If the API supports a read-only key limited to that customer’s account, a private key may meet the requirement. Separate credentials for reporting and fulfilment would allow one connection to be disabled without interrupting the other. Sharing a single unrestricted key would make that separation harder.
The product work includes deciding who can generate a key, how its purpose is recorded and how the customer replaces it. Rotation means issuing a replacement and retiring the old credential. If replacement requires a maintenance window or intervention from support, that cost belongs in the integration plan. Where the provider already requires OAuth client credentials, the same reporting process would need token acquisition and renewal instead.
A second hypothetical feature lets merchants connect an external forecasting application. Each merchant needs to authorize access to its own order history, understand the requested permissions and remove that connection independently. A delegated OAuth flow is a good fit when the API supports it, because the merchant can authorize the application through the provider instead of copying a private key into a third-party form.
The connection can still fail after onboarding. An administrator may withdraw access, an account may lose a required permission or a credential may expire. The forecasting product needs a visible connection status and a recovery path. Repeatedly retrying an authorization failure without telling anyone would leave merchants making decisions from stale forecasts.
Revocation needs a product definition
“Disconnect” can mean stopping future synchronization, revoking the provider’s authorization, removing stored credentials or deleting previously imported information. These are separate operations. Removing a connection does not automatically erase data that has already been copied, so retention and deletion behaviour need their own requirements.
Access may also take time to stop. OAuth providers differ in how they invalidate issued tokens; revoking a refresh token can prevent renewal while an existing access token remains usable until expiry. API key revocation also depends on how the service enforces it. The team should establish the expected behaviour before promising immediate disconnection.
Questions to settle before launch
A useful review starts with the operations the integration needs and the account on whose behalf it acts. That makes it possible to inspect the available permissions and agree on what happens during credential replacement or loss of access. The following questions can become acceptance criteria:
- Can the integration read only the required data, and can it modify or delete anything unnecessarily?
- Can each customer and integration have separate access, with a clear record of who approved it?
- Can credentials be renewed or rotated without interrupting scheduled work?
- After disconnection, how long could requests still succeed, and what happens to data already imported?
- Who is notified when authorization fails, and how does the customer restore the connection?
The broader guide to APIs for Product Managers covers requests, responses and integration dependencies. For the distinction between identity and permitted actions, see authentication vs. authorization. The books APIs for Product Managers and Security for Product Managers develop these integration and access decisions in more detail.
Technical references
- Stripe: API keys and restricted permissions.
- Google: OAuth 2.0, scopes and token renewal.
- IETF RFC 6749, section 4.4: client credentials.
- IETF RFC 7009: token revocation and RFC 9700: current OAuth 2.0 security practice.