OAuth2 vs API Key: Which Authentication Do You Actually Need
6 min read · Updated Jul 17, 2026
Use an API key when your own application or script is calling an API on its own behalf, with a secret only you hold. Use OAuth2 (a protocol, standardised in RFC 6749 back in 2012, that issues short-lived access tokens on a user’s behalf) the moment a user needs to grant your application access to their account on a separate service, like reading their Google Calendar or posting to their Slack workspace. Confusing the two is the most common API authentication mistake beginners make, and it usually ends with either a broken integration or a leaked secret.
Key takeaways
- An API key is one static secret sent with every request. It proves the application, not the individual end user, is authorized.
- OAuth2 issues a short-lived access token after a user explicitly grants permission, and that token can be revoked without changing any password.
- API keys are simpler to implement but harder to scope narrowly and easy to leak if committed to a public repository.
- OAuth2 adds real complexity (redirect flows, refresh tokens, expiry handling) that is only worth it when a third party’s user data is involved.
- Never use an API key to act on behalf of an individual end user of someone else’s service. That is what OAuth2 exists to solve properly.
The one-sentence version of the difference
An API key answers the question "which application is calling me." OAuth2 answers a harder question: "which application is calling me, on behalf of which specific user, with which specific permissions, and for how long." If your integration only ever needs the first answer, OAuth2 is unnecessary complexity. If it needs the second, an API key cannot honestly provide it.
API keys: simple, static, and easy to misuse
An API key is a long random string. You put it in a header, usually Authorization: Bearer or a custom header like X-API-Key, on every request. The server checks it against a database of valid keys and either allows or rejects the request. There is no user consent flow, no redirect, no expiry unless the provider builds one in separately.
curl https://api.example.com/v1/items \
-H "Authorization: Bearer sk_live_51Hxyz..."The commit that taught me this the hard way
Early in 2016 I pushed a small integration script to a public repository with a payment provider’s API key hardcoded directly in a config file, reasoning I would "remove it before anyone saw it." A scraper bot found it within about four hours, well before I got around to removing it. The provider’s dashboard flagged unusual usage the same afternoon and I caught it before real damage was done, but the key had to be rotated and every downstream service using it updated the same day. I have used environment variables and a secrets manager for every key since, and I still double check git diff before every commit that touches a config file.
OAuth2: more steps, but it solves a problem API keys cannot
OAuth2 exists because sometimes your application needs to act on behalf of a specific user of a different service, and that user should never have to hand you their password to make it work. The flow: your app redirects the user to the provider (Google, Slack, GitHub), the user approves specific scopes ("read your calendar", "post messages as you"), the provider redirects back with an authorization code, and your server exchanges that code for a short-lived access token plus a longer-lived refresh token.
curl https://oauth.example.com/token \
-d grant_type=authorization_code \
-d code={{AUTH_CODE_FROM_REDIRECT}} \
-d client_id={{CLIENT_ID}} \
-d client_secret={{CLIENT_SECRET}} \
-d redirect_uri={{YOUR_REDIRECT_URI}}The access token that comes back typically expires in an hour or less. Your app uses the refresh token to silently get a new one without bothering the user again, until the user revokes access entirely from their account settings on the provider’s side. That revocation path, doable without changing a password, is the feature an API key structurally cannot offer.
Side by side
| Factor | API key | OAuth2 |
|---|---|---|
| Setup complexity | Low, one header, done | Higher, redirect flow, token exchange, refresh logic |
| Acting on behalf of an end user | Not designed for this | This is exactly what it solves |
| Revocation without a password change | Requires manually rotating the key | User revokes access from their own account settings |
| Best fit | Server-to-server, your own scripts, internal tools | Third-party integrations acting for a specific user |
I think a lot of beginner confusion here comes from tutorials that use "authentication" as one generic concept instead of naming which problem each method solves. Once you internalise that an API key answers "which app" and OAuth2 answers "which app, for which user, with which permissions", the decision mostly makes itself based on what your integration is actually trying to do.
“The four hours between pushing a leaked key and a bot finding it taught me more about authentication than any documentation ever did.”
Frequently asked questions
Frequently asked questions
When should I use an API key instead of OAuth2?
Use an API key when your own application or script is calling the API on its own behalf, without needing to act as a specific end user of another service. Server-to-server integrations, internal tools, and personal automation scripts are the typical fit.
Why is OAuth2 more complex than an API key?
Because it solves a harder problem: granting scoped, revocable, time-limited access to a specific user’s data without that user ever sharing their password. The redirect flow, token exchange, and refresh logic all exist to make that possible safely.
What happens if an API key leaks?
Anyone holding it has full access to whatever it authorizes until you rotate it, since API keys carry no built-in expiry or per-user scoping. Rotate the key immediately, audit for any unusual usage, and update every service that referenced the old key.
Can a user revoke access without changing their password?
With OAuth2, yes, from their account settings on the provider’s side, which immediately invalidates the associated tokens. With a plain API key, there is no equivalent per-user revocation, since the key does not represent an individual user in the first place.
Does n8n support both API key and OAuth2 authentication?
Yes. n8n’s credentials system supports header-based API keys and full OAuth2 flows for its built-in integrations. Which one you use is determined by what the target API requires, not a preference you set in n8n itself.