How API Authentication Works
IntermediateAPI authentication is how a server verifies who is calling it before serving a request. Because APIs are consumed by other software rather than people at a login form, they use credentials that travel with each request: an API key, a bearer token (often a JWT), an OAuth access token, an HMAC signature, or a client certificate (mTLS). Each method trades simplicity against security and revocability. Choosing the right one depends on who the caller is and what the API protects.
Think of ways to prove who you are at a building
An API key is like a keycard: simple, but anyone holding it gets in, so losing it is dangerous. A bearer token is a wristband that expires at the end of the day — convenient, but whoever wears it is trusted. OAuth is a visitor pass issued by reception after checking you elsewhere. An HMAC signature is signing each request so tampering is detectable. mTLS is both you and the building showing verified ID to each other. Different doors call for different proof.
Step by Step
Key Concepts
Authentication vs Authorization
Authentication verifies who the caller is; authorization decides what they may do. API auth handles the first; scopes, roles, and policies handle the second — usually after authentication succeeds.
Bearer Token
Any token where mere possession grants access ("the bearer"). API keys and JWTs are bearer credentials, which is why they must be sent over HTTPS and kept secret.
JWT (self-contained token)
A signed token carrying claims the server verifies by signature alone, enabling stateless authentication with no per-request database lookup — but it cannot be easily revoked before expiry.
mTLS
Mutual TLS where both parties present and verify certificates. It authenticates the client and server to each other cryptographically, widely used for internal service-to-service security.
Key Facts
- API keys identify an application, not a user, and grant whatever access the key allows — treat them as sensitive secrets and rotate them.
- JWTs enable stateless auth but are hard to revoke before expiry, so keep their lifetime short and use refresh tokens or a denylist for revocation.
- Always send credentials over HTTPS; a bearer token or API key intercepted on plain HTTP gives an attacker full access.
Real-World Applications
A public developer API
A SaaS issues API keys to developers to identify and rate-limit their apps, often layered with HMAC signing for sensitive endpoints so requests cannot be tampered with in transit.
User-facing app with JWTs
After login, a web or mobile app receives a short-lived JWT and sends it as a bearer token on each API call; the server verifies the signature and reads the user and roles from the claims without a database hit.
Frequently Asked Questions
What are the main methods of API authentication?
The common methods are: API keys (a static shared secret identifying an application), bearer tokens including JWTs (sent in the Authorization header, often self-contained and signed), OAuth access tokens (short-lived, scoped tokens issued after user consent for third-party access), HMAC request signing (signing each request with a secret so tampering is detectable), and mutual TLS (both client and server present certificates). Each trades simplicity for security and revocability.
What is the difference between an API key and a JWT?
An API key is a static shared secret that identifies the calling application; it typically does not expire on its own and carries no structured information, so anyone holding it has whatever access it grants. A JWT is a signed, self-contained token carrying claims like the user, roles, and an expiry; the server verifies it by signature without a database lookup. JWTs support stateless, user-level authentication with expiry, while API keys are simpler, application-level identifiers.
Why must API credentials be sent over HTTPS?
Most API credentials — API keys and bearer tokens including JWTs — are bearer secrets, meaning whoever possesses them is granted access. If sent over plain HTTP, they can be intercepted on the network, and the attacker then has full access to the API as that caller. HTTPS encrypts the request so the credential cannot be read in transit, which is why it is mandatory for any authenticated API.
What is mTLS and when is it used?
Mutual TLS (mTLS) is an authentication method where both the client and the server present certificates and verify each other during the TLS handshake, so each side cryptographically proves its identity. It is strong and commonly used for internal service-to-service communication — for example within a service mesh — where you want mutual, certificate-based trust between services rather than relying on shared secrets or bearer tokens.