HMAC vs OAuth vs API Keys vs Bearer Tokens

Choosing the Right API Authentication Strategy

If you’ve ever integrated with a payment gateway, banking API, webhook provider, or enterprise platform, you’ve probably come across a confusing mix of authentication options: API Keys, Bearer Tokens, OAuth, HMAC, and Mutual TLS (mTLS).

A common question is: Why are some financial systems still using HMAC when OAuth exists?

The answer is simple: These mechanisms solve different problems.

Let’s break them down in plain English.

The Authentication Landscape

When one system talks to another, there are three fundamental questions:

1. Who is making this request?
2. Is this request allowed?
3. Has the request been modified along the way?

Different authentication methods answer different parts of those questions.

1. API Keys

The simplest approach.

A client sends a key with every request.

X-API-Key: abc123

The server checks whether the key is valid.

If yes: ✅ Request accepted

If no: ❌ Request rejected

Pros

• Very easy to implement
• Easy to test
• Minimal infrastructure

Cons

• No protection against payload tampering
• If the key leaks, anyone can use it
• No proof that a request actually came from a trusted system

Best Use Cases

• Internal tools
• Low-risk APIs
• Development environments

2. Bearer Tokens

You’ve probably seen this:

Authorization: Bearer eyJhbGciOi...

The keyword is “Bearer”.

It literally means: Whoever possesses this token can use it.

If someone has the token, they can access the API until the token expires.

Pros

• Widely supported
• Easy to integrate
• Works well with user authentication

Cons

• Token theft is a risk
• Requires token management
• Requires token expiration and refresh handling

Best Use Cases

• Mobile applications
• Web applications
• User-facing APIs

3. OAuth 2.0

OAuth is often mistaken as an authentication mechanism. It’s actually more about authorization.

OAuth answers: What is this application allowed to do?

Imagine logging into a third-party website using Google.

Google asks:

Allow this application to:
✓ View profile
✓ Read email

The user approves.

The application receives an access token.

That token represents permissions granted by the user.

Pros

• Fine-grained permissions
• User delegation support
• Industry standard
• Strong ecosystem

Cons

• More complex than API Keys
• Token lifecycle management required
• Can be overkill for simple system-to-system communication

Best Use Cases

• Google APIs
• Microsoft Graph
• GitHub Apps
• Open Banking APIs
• Any API acting on behalf of users

4. HMAC Authentication

Now we get to the interesting one.

HMAC stands for: Hash-based Message Authentication Code

Instead of sending a secret key directly, both systems share a secret.

The sender generates a signature.

Signature =
HMAC_SHA256(
    secretKey,
    requestData
)

The receiver performs the same calculation.

If both values match:

✅ The sender knows the secret

✅ The request wasn’t changed

Why HMAC Is So Popular in Payments

Payment providers care deeply about two things:

1. Authenticity
2. Integrity

They need to know:

• Who sent the request?
• Has any field been modified?

Consider this payload:

{
  "amount": 100
}

Imagine an attacker changes it to:

{
  "amount": 10000
}

The signature immediately becomes invalid.

The server rejects the request.

This is one reason HMAC remains extremely popular in payment systems and webhook integrations.

What Gets Signed?

This is where integrations often get tricky. Different providers sign different parts of the request.

Get Shashi Raj’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Option 1: Request Body Only

HMAC(secret, body)

Option 2: Timestamp + Body

HMAC(secret, timestamp + body)

Option 3: Method + Path + Body

HMAC(secret,
      POST
      + /payments
      + body)

Option 4: Canonical Request

Method
URI
Query Parameters
Headers
Payload

This is similar to what AWS Signature V4 uses.

The more components included, the harder it becomes for attackers to manipulate requests.

What Problem Does HMAC Solve?

HMAC answers two critical questions:

Question 1 : Did the request come from someone who knows the shared secret? ✅ Yes

Question 2 : Has the message been changed since it was signed? ✅ Yes

This combination makes HMAC powerful.

Why Not Just Use HTTPS?

A very common question.

HTTPS protects communication while data travels over the network.

HMAC protects the message itself.

Think of it like this:

HTTPS = Secure Delivery Truck

HMAC = Tamper-Proof Package Seal

Both are valuable.

Most real-world implementations use both.

OAuth vs HMAC

This comparison causes confusion more than any other.

The reality is: OAuth and HMAC are not competitors.

They serve different purposes.

OAuth

Focuses on:

Authorization

Questions answered:

What can this application do?
Who granted permission?

HMAC

Focuses on:

Authentication and Integrity

Questions answered:

Who sent this message?
Was it modified?

When OAuth Wins

Choose OAuth when:

Users are involved

Consent is required

Permissions need to be delegated

Access must be revocable

Examples:

• Google APIs
• Microsoft Graph
• GitHub Apps
• Open Banking platforms

When HMAC Wins

Choose HMAC when:

System-to-system communication

Payment gateways

Banking integrations

Webhooks

High-volume API traffic

No user login involved

Examples:

• Merchant → Payment Processor
• Payment Processor → Webhook Consumer
• Internal Microservices
• Digital Wallet Integrations

What About Mutual TLS (mTLS)?

Another common option.

Instead of shared secrets, systems exchange certificates.

Client:

I am Client A

Server:

Prove it with your certificate

Client:

Here's my certificate

Server validates it and accepts the connection.

Pros

• Very strong identity verification
• Difficult to impersonate

Cons

• Certificate management overhead
• Renewals and rotations
• Operational complexity

Because of this, many payment providers combine:

mTLS + HMAC

for extra security.

A Simple Mental Model

If a human user is involved:

👉 Think OAuth.

If two backend systems are talking directly:

👉 Think HMAC.

If identity assurance must be extremely strong:

👉 Think mTLS.

If you’re building a quick internal service:

👉 API Keys may be enough.

Final Thoughts

There is no single “best” authentication mechanism.

The right choice depends on the problem you’re solving.

A good architecture often combines multiple layers:

HTTPS
   +
OAuth
   +
HMAC
   +
mTLS

Every layer addresses a different risk.

The most important takeaway is this:

OAuth proves permissions. HMAC proves message integrity. HTTPS protects transport. mTLS proves client identity.