API authentication answers one question — who, or what, is making this request — and there are several established ways to answer it, each suited to a different situation. Picking the wrong one is a common source of avoidable security debt: API keys for a user-facing app, OAuth for a machine-to-machine job, or a hand-rolled token scheme anywhere, all tend to cause problems later that a standard approach would have avoided.
What changed in 2026
- mTLS adoption grew for internal service-to-service traffic, driven by service mesh tooling that now handles certificate rotation automatically, removing the old operational pain point.
- OAuth 2.1 consolidation continued, folding in security best practices (like mandatory PKCE) that used to be optional extensions, tightening the default posture for new implementations.
- API key scoping and short-lived key support improved across major API gateway products, narrowing the gap between "simple key" and "properly scoped credential."
The main methods, side by side
| Method |
Authenticates |
Typical use case |
Weakness |
| API key |
An application or account |
Simple server-to-server or partner APIs |
No user delegation, easy to leak if not scoped |
| OAuth 2.0 / 2.1 |
A user, via delegated access |
Third-party apps acting on a user's behalf |
More complex to implement correctly |
| JWT (bearer token) |
Whatever issued it (often paired with OAuth) |
Stateless session or access tokens |
Cannot be revoked before expiry without extra infrastructure |
| mTLS |
The calling service itself |
Internal service-to-service traffic |
Certificate management overhead |
| HMAC signed requests |
The request payload plus a shared secret |
Webhooks, payment APIs |
Requires careful implementation to avoid replay attacks |
API keys: simple, and limited on purpose
An API key is a static credential passed with each request, usually in a header. It is easy to implement and easy to understand, which is exactly why it is the wrong tool for anything beyond low-risk or internal use — a leaked key grants full access until manually revoked, and keys carry no concept of "on behalf of a specific user."
GET /v1/reports HTTP/1.1
Host: api.example.com
Authorization: Bearer sk_live_51H8x...
OAuth 2.0: delegated access done properly
OAuth solves a different problem: letting a user grant a third-party app limited access to their account without handing over a password. The app receives a token, often a JWT, scoped to specific permissions and a specific expiry. This is the right model any time a user is authorizing an external application — think "Sign in with" flows or an app requesting calendar access.
JWTs and mTLS: the pieces underneath
A JWT (JSON Web Token) is a signed, self-contained data format — it is not an authentication method on its own, but the token format most OAuth and session systems issue. Its self-contained nature is both the appeal (no database lookup needed to validate) and the risk (it cannot be revoked before expiry without a denylist or short lifetimes). mTLS, by contrast, authenticates connections rather than requests — both client and server present certificates, proving mutual identity before any application data flows. It fits internal service-to-service traffic well and user-facing APIs poorly, since you cannot expect a browser user to manage a client certificate.
Choosing the right method
Match the method to who or what is authenticating. A public-facing API used by third-party developers usually needs OAuth. Internal services calling each other inside a trusted network benefit from mTLS. Simple integrations and internal tools can use scoped, short-lived API keys. Most production systems for a real business use more than one of these together, not a single method for everything.
FAQ
Is a JWT more secure than an API key?
Not inherently — they solve different problems. A JWT typically carries an expiry and can encode claims; a static API key does not expire unless you build that in yourself.
Can I use OAuth for service-to-service authentication?
Yes, via the client credentials grant, though mTLS or short-lived signed tokens are often a better operational fit for pure machine-to-machine traffic.
How do I revoke a JWT before it expires?
You need extra infrastructure — a denylist, short token lifetimes with refresh, or a token introspection endpoint. JWTs are not revocable by design.
Should small projects bother with OAuth?
Only if you have third-party apps or users delegating access. For a single internal API, a properly scoped API key is often simpler and sufficient.
Where to go next