What is the difference between an API key and OAuth, and which should we use?
An API key is one long-lived secret that identifies an application. OAuth issues a token on behalf of a specific account, usually short-lived, scoped to particular permissions, and revocable. Keys are simpler and more dangerous. OAuth is more work and gives you scoping, revocation, and an audit trail showing which account performed each action. Most vendors are moving to OAuth.
What each one actually proves
An API key proves that whoever is calling has the key. That is all. It carries no identity, no expiry in most cases, and often no scope, so a leaked key is full access until someone notices and rotates it.
An OAuth token proves that a specific account granted a specific application a specific set of permissions, and that the grant has not been revoked. The token expires on its own; a refresh token quietly obtains a new one. The distinction matters most on the day someone needs to cut off access without breaking the other six integrations.
The consequences you should plan for
- Whose account authorized it? If an integration was connected under a manager's login and that manager leaves, the integration dies with their account. Connect through a dedicated service account owned by the business.
- Scopes are requested up front. Adding a permission later usually means re-authorizing, which means finding the person with the right credentials, again. Request what the project will need, not only what the first phase needs.
- Refresh tokens can rotate. Some vendors issue a new refresh token on every use and invalidate the old one. If two copies of your integration run at once, they will fight and both lose access.
- Sandbox and production credentials differ. They are not interchangeable, and confusing them is a classic way to write test data into a live system.
Rules that apply either way
Credentials belong in a secret store, never in a spreadsheet, a shared inbox or a code repository. Each integration gets its own credential so you can revoke one without disturbing the rest. Permissions follow least privilege, which for reporting work usually means read-only. And the account used should be identifiable in the vendor's audit log, so that when a record changes, the log says "integration" rather than the name of an employee who was at lunch.
These are unremarkable practices, but they are the ones that make an integration layer safe to hand to a client rather than a liability that lives in one developer's laptop.
Which to use when you have a choice
If the vendor supports OAuth, use it. If they only offer keys, treat the key as you would a master password: stored centrally, rotated on a schedule, restricted by IP where the vendor allows it, and monitored so unusual usage is visible. The extra effort is small compared to explaining a credential leak, and it is part of what we set up in every systems integration engagement.
Topics: OAuth · API keys · authentication · security
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.