Authentication Methods

HTTP Basic

Username and password sent in the Authorization header, Base64-encoded.

Authorization: Basic ZGVtbzpwYXNzd29yZA==

Simple but blunt: credentials are sent on every request. Only acceptable over TLS, and only for machine-to-machine or for internal admin tools where the overhead of a fancier scheme isn't worth it. The 401 challenge triggers the browser's native login dialog.

Bearer tokens

An opaque or structured token (often a JWT) sent in the Authorization header. Anyone holding the token can use it — there is no secondary proof of identity. Tokens should be short-lived and bound to a specific audience.

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

API keys

A long random string identifying a calling application. Typically sent in a custom header (X-API-Key) or query parameter. Best for server-to-server integration and not for end users. Should be revocable and scoped to specific permissions.

Session cookies

The classic browser-friendly approach. The server sets an opaque session ID in a cookie with HttpOnly; Secure; SameSite=Lax; subsequent requests carry it automatically. Session state lives on the server (in a store like Redis) or is encrypted and signed in the cookie itself.

OAuth 2.0

A delegation framework, not strictly an authentication protocol. It lets a user grant a third-party app limited access to their account on a service, without sharing the password. See OAuth 2.0 Flows for the four common patterns.

OpenID Connect (OIDC)

An authentication layer on top of OAuth 2.0. Adds an id_token (a JWT) that asserts who the user is, alongside the access token. The de-facto SSO standard for modern web and mobile apps.

Mutual TLS (mTLS)

Both parties present X.509 certificates during the TLS handshake. Strongest available — no bearer secrets in flight, identity is bound to a key the client holds. Common in service mesh and zero-trust networks; less common at the public Internet edge because cert provisioning is heavyweight.

Choosing