authentication
Authorization
Carries client credentials to the server per the scheme announced in a prior WWW-Authenticate challenge (or agreed out of band). The scheme names the auth mechanism; the credentials are its scheme-specific payload.
Authorization: <scheme> <credentials> (e.g. Bearer <token>, Basic <base64(user:pass)>, Digest ..., DPoP ...) Common directives / values
| Directive | Purpose |
|---|---|
| Bearer <token> | OAuth 2.0 / JWT bearer token (RFC 6750) — dominant modern scheme. |
| Basic <base64> | base64(user:password) — only safe over HTTPS (RFC 7617). |
| Digest ... | Challenge/response with nonce and hash — legacy, mostly obsolete. |
| DPoP <proof> | Proof-of-possession bound token (RFC 9449) — complements Authorization with a DPoP header. |
| AWS4-HMAC-SHA256 ... | AWS SigV4 request signing scheme. |
Examples
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... Standard JWT bearer for OAuth 2.0-protected APIs.
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l HTTP Basic — 'aladdin:opensesame' base64-encoded; HTTPS only.
curl -H 'Authorization: Bearer $TOKEN' https://api.example.com/v1/me Common curl invocation against a token-protected endpoint.
Authorization: Digest username="user", realm="api", nonce="...", uri="/protected", response="..." Digest auth response to a 401 challenge; largely legacy.
Gotcha
Basic is plaintext once base64-decoded — never send it over HTTP. Bearer tokens are equally sensitive: leaking one in logs/URLs/Referer grants full impersonation until it expires or is revoked.
Related headers
WWW-Authenticate
Sent in a 401 response to challenge the client for credentials using the named scheme(s). May appear multiple times to offer alternatives; each carries scheme-specific parameters like realm and error codes.
Cookie
Client sends previously stored cookies that match the request's origin, path, and Secure/SameSite constraints. All applicable name=value pairs are concatenated into a single header.
Set-Cookie
Server instructs the client to store a cookie with attributes governing lifetime, scope, and security. Each cookie needs its own Set-Cookie header — they are the one HTTP header that MUST NOT be comma-folded.