10 authentication methods — Basic, Bearer, OAuth 2.0, JWT, mTLS and more. How they work, transport, and security considerations.
HTTP Basic authentication (RFC 7617) is the simplest scheme: it joins a username and password with a colon, Base64-encodes the result, and sends it in the Authorization header on every request. With no session or token-issuance step, it is trivial to implement and still common for internal tools, health checks, and proxy authentication.
Bearer authentication (RFC 6750) sends a previously issued opaque token or JWT in the `Authorization: Bearer <token>` header. It is the standard for OAuth 2.0 and most modern REST APIs. As the name implies, whoever bears (holds) the token is granted access.
Digest authentication (RFC 7616) is a challenge-response scheme built to avoid sending the password in cleartext or Base64. The server issues a nonce (one-time value); the client hashes the username, password, nonce, request method, and URI and sends only that digest, so the raw password never crosses the wire.
An API key is a long random string that identifies the calling client (usually a server, script, or SDK), typically sent in an `X-API-Key` or `Authorization` header. It identifies which application or project is calling rather than a human user, and is geared toward quotas, billing, and rate limiting.
OAuth 2.0 (RFC 6749) is an authorization framework that lets a user delegate limited access to a resource without handing their password to a third-party app. The classic scenario is 'let this app read only my Google Calendar' without giving it your Google password.
OpenID Connect (OIDC) adds an authentication (who you are) layer on top of OAuth 2.0. It fills the gap OAuth left, delivering the user's identity in a verifiable form via a signed JWT called the ID Token. It is the protocol behind 'Sign in with Google/Apple/Kakao' buttons.
A JWT (JSON Web Token, RFC 7519) is a self-contained token that carries signed claims as JSON, encoded as three Base64URL parts joined by dots: `header.payload.signature`. Because the server can trust the contents by verifying the signature alone, without a session lookup, JWTs are the de facto standard for stateless authentication.
HMAC signature authentication signs the request itself with a shared secret key, simultaneously proving the sender's identity and the request's integrity (that it was not tampered with). AWS Signature V4 is the canonical example; it is used for payments, webhooks, and server-to-server APIs where preventing tampering and replay matters.
Mutual TLS (mTLS) extends ordinary TLS, where only the server is verified by certificate, so that the client also presents its own X.509 certificate and both sides verify each other. Authentication happens at the transport layer (the TLS handshake), not the application layer, and it provides strong identity assurance for service-to-service traffic, zero-trust networks, and finance/IoT.
The session cookie is the classic web login method: on successful login the server issues a random session ID and sends it via `Set-Cookie`, and the browser then attaches it automatically as a `Cookie` header on every request. The proper design keeps the real user state (login info, permissions) in a server-side session store and puts only an identifier pointing to that store in the cookie.