API Security
API Authentication Methods Explained: Keys, OAuth, JWT & More
API authentication methods: API keys (simple, identify applications, low security), OAuth 2.0 (industry standard, delegated authorization, scoped access), JWT (self-contained tokens for stateless verification), mutual TLS/mTLS (certificate-based, strongest machine-to-machine auth), HMAC (request signing for integrity verification), and Basic Auth (username/password, only acceptable over TLS for simple cases). Choose based on security requirements: OAuth 2.0/JWT for user-facing APIs, mTLS for high-security service-to-service, API keys for public data.
Andreas Johansson · Chief Executive Officer
Senior IT management leader with 25 years of experience in Cloud, Security, and Datacenter infrastructure.
Choosing the Right Authentication Method
API authentication verifies the identity of the caller — whether it's a user, application, or service. The right method depends on who's calling (users vs machines), what they're accessing (public vs sensitive data), and your operational requirements.
API Keys
How They Work
API keys are unique strings assigned to applications or users. The client includes the key in each request, typically in a header:
X-API-Key: sk_example_abc123def456...Strengths
- Simple to implement and use
- Easy to generate, rotate, and revoke
- Good for identifying calling applications
- Effective for rate limiting and usage tracking
Weaknesses
- Keys identify applications, not users (no user-level authorization)
- No built-in expiration mechanism
- If leaked, full access until manually revoked
- No standard for scope limitation
- Often embedded in client code where they can be extracted
When to Use
- Public data APIs where identifying the caller is sufficient
- Simple server-to-server integrations
- Rate limiting and analytics tracking
- APIs where user-level identity isn't needed
Security Best Practices
- Transmit in headers, never URLs
- Use different keys for different environments (dev, staging, production)
- Implement key rotation without downtime
- Monitor key usage for anomalous patterns
- Treat keys as secrets — don't commit to repositories
OAuth 2.0
How It Works
OAuth 2.0 is a delegated authorization framework. Instead of sharing credentials, users authorize applications to act on their behalf with specific, scoped permissions.
- Key components:
- Authorization server — issues tokens after user authentication
- Resource server — the API that verifies tokens and serves data
- Client — the application requesting access
- Scopes — define what the client can do (read, write, admin)
- Flows:
- Authorization Code — web applications (most secure for user-facing apps)
- Authorization Code + PKCE — mobile and single-page applications
- Client Credentials — machine-to-machine (no user involved)
- Device Code — devices without browsers (smart TVs, CLI tools)
Strengths
- Industry standard with extensive library support
- Scoped access — users grant specific permissions
- Token expiration and refresh mechanisms
- Supports multiple application types
- Separation of authentication and authorization concerns
Weaknesses
- Complex to implement correctly
- Multiple flows create configuration complexity
- Token management overhead
- Requires understanding of security implications per flow
When to Use
- User-facing APIs where users authorize third-party access
- Any API requiring granular permission scoping
- APIs serving multiple client types (web, mobile, server)
- Enterprise APIs with complex authorization requirements
JSON Web Tokens (JWT)
How They Work
JWTs are self-contained tokens that carry identity claims, signed to prevent tampering:
{
"header": {"alg": "RS256", "typ": "JWT"},
"payload": {"sub": "user-123", "scope": "read write", "exp": 1625000000},
"signature": "..."
}The API verifies the signature and extracts user information without a database lookup.
Strengths
- Stateless — no server-side session storage needed
- Self-contained — carry user identity and permissions
- Scalable — any server with the verification key can validate tokens
- Standard format with extensive library support
Weaknesses
- Can't be revoked before expiration (without additional infrastructure)
- Payload is encoded, not encrypted — don't store secrets in JWTs
- Size grows with claims — adds overhead to every request
- Signature algorithm confusion attacks if not validated properly
Security Best Practices
- Use asymmetric signing (RS256) for tokens verified by multiple services
- Validate all claims: signature, expiration (exp), issuer (iss), audience (aud)
- Keep tokens short-lived (15-60 minutes)
- Don't store sensitive data in JWT payload (it's Base64-encoded, not encrypted)
- Explicitly specify and validate the signing algorithm — never accept
none
Mutual TLS (mTLS)
How It Works
In standard TLS, only the server presents a certificate. In mutual TLS, both client and server present certificates, providing bidirectional authentication.
Strengths
- Strongest machine-to-machine authentication
- No tokens to leak or manage
- Authentication at the transport layer (before application code)
- Certificate-based identity is difficult to spoof
Weaknesses
- Complex certificate management (issuance, distribution, rotation, revocation)
- Not practical for user-facing APIs (users don't have client certificates)
- Debugging TLS issues is more complex
- Certificate infrastructure (PKI) required
When to Use
- High-security service-to-service communication
- Internal microservice authentication
- Financial and healthcare APIs with strict security requirements
- Zero-trust network architectures
HMAC (Hash-based Message Authentication Code)
How It Works
The client signs each request using a shared secret. The signature covers the request method, URL, timestamp, and body — ensuring requests can't be tampered with or replayed.
Signature = HMAC-SHA256(secret, method + url + timestamp + body_hash)Strengths
- Request integrity — tampering is detected
- Replay protection — timestamps prevent request reuse
- Secret never transmitted — only the signature is sent
- Lightweight — no token infrastructure needed
Weaknesses
- Shared secret management — both parties need the secret
- Request signing complexity — clients must correctly construct the signature base
- Timestamp synchronization required between client and server
- No standard format (each API implements differently)
When to Use
- Webhook verification (proving the webhook came from the expected source)
- Server-to-server communication where request integrity is critical
- APIs where transmitting credentials is unacceptable
Authentication Method Selection
| Scenario | Recommended Method |
|---|---|
| Public data API | API Key |
| User-facing SaaS API | OAuth 2.0 + JWT |
| Mobile app backend | OAuth 2.0 (PKCE) + JWT |
| Microservice-to-microservice | mTLS or JWT (client credentials) |
| High-security financial API | mTLS + OAuth 2.0 |
| Webhook delivery | HMAC |
| Simple internal tools | API Key or Basic Auth (over TLS) |
How SeqOps fits
SeqOps doesn't test APIs. It checks the cloud and server infrastructure your APIs run on, such as network exposure, access settings and unpatched software, so the platform underneath your APIs isn't the weak point.