HTTP authentication is the process of proving who made a request. HTTP is stateless, so every request must identify itself. When a server requires authentication for a protected resource, it responds with 401 Unauthorized and a WWW-Authenticate header naming the scheme it expects.
GET /v1/me HTTP/1.1
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api", error="invalid_token"Basic vs Bearer
The two most basic Authorization schemes are Basic and Bearer. Basic sends username:password Base64-encoded. Beware: Base64 is encoding, not encryption — anyone can reverse it. So Basic must only ever run over HTTPS.
GET /v1/me HTTP/1.1
Authorization: Basic dXNlcjpwYXNzd29yZA==
GET /v1/me HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...Bearer means 'grant access to whoever bears this token.' You send a previously issued token (usually an OAuth 2.0 access token or a JWT) as-is. Possession of the token is sufficient, so a leaked token is immediately abusable. That's why Bearer also requires HTTPS, and tokens should carry short expirations.
401 vs 403
This is the most commonly confused pair. Despite its name, 401 Unauthorized means an authentication failure — 'I don't know who you are; present credentials.' 403 Forbidden means 'you're authenticated and I know who you are, but you lack authorization for this action.' Logged in but hitting an admin-only page → 403. Not logged in, or an expired token → 401.
Tokens/JWT vs sessions/cookies
There are two broad families for keeping someone authenticated across requests.
- Sessions + cookies (stateful): The server creates and stores a session and hands the client a session ID in a cookie. Because the server holds the state, instant logout/invalidation is easy — but scaling across many servers requires sharing sessions.
- Tokens like JWT (stateless): User claims and a signature live inside the token, so the server only verifies the signature. This scales well with no server-side session store, but revoking an issued token before it expires is hard (you need a blacklist or similar).
When you use cookies, the security attributes matter. HttpOnly blocks JavaScript access and protects the token from XSS; Secure restricts it to HTTPS; SameSite mitigates CSRF. Storing a Bearer token in the browser's localStorage is XSS-exposed, so an HttpOnly cookie is often the safer choice.
Why HTTPS is required
Whether Basic or Bearer, credentials and tokens travel in request headers essentially in the clear. Sent without HTTPS, an attacker on the same network can sniff and reuse them to take over the account. Every form of authentication must therefore run over TLS (HTTPS) — not optional, but a minimum requirement.