HTTP Authentication

HTTP authentication is the framework for controlling access to server resources. A server challenges a client by responding with a 401 status code and a WWW-Authenticate header specifying which authentication schemes are accepted. The client then resubmits the request with credentials in the Authorization header.

How authentication works

The HTTP authentication framework follows a challenge-response model. When a client requests a protected resource without valid credentials, the server responds with 401 and includes one or more challenges in the WWW-Authenticate header. Each challenge names an authentication scheme and provides parameters the client needs to construct credentials.

The client selects a scheme, constructs the credentials, and resubmits the request with an Authorization header. On success, the server returns the resource. On failure, the server returns another 401.

After successful authentication, the server sends an Authentication-Info header in some schemes (notably Digest) to provide updated parameters like a new nonce or a response digest for mutual verification.

Protection spaces

A protection space (realm) groups resources sharing the same authentication requirements. The realm parameter in a WWW-Authenticate challenge identifies which credentials apply. A single server hosts multiple realms, each requiring different credentials. Clients cache credentials per realm and apply them to subsequent requests targeting the same protection space.

Authentication schemes

The IANA HTTP Authentication Scheme Registry maintains the full list of registered schemes. The most commonly encountered schemes are described below.

Basic

Basic authentication transmits a username:password pair encoded in Base64. The Authorization header carries the encoded credentials.

Authorization: Basic dXNlcjpzZWNyZXQxMjM=

Decoding dXNlcjpzZWNyZXQxMjM= reveals user:secret123. Because Base64 is encoding rather than encryption, Basic authentication provides no confidentiality on its own. Pairing Basic with HTTPS is essential to protect credentials in transit.

Bearer

Bearer authentication relies on opaque access tokens, most commonly issued through an OAuth 2.0 authorization flow. The client presents the token in the Authorization header.

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

The token is opaque to the client. The server validates the token and determines whether the associated permissions (scopes) grant access to the requested resource. Bearer tokens are the dominant authentication mechanism for APIs.

Digest

Digest authentication improves on Basic by hashing credentials with a server-provided nonce. The password never travels in cleartext. The server sends a challenge with realm, nonce, and qop (quality of protection) parameters. The client computes a hash of the credentials, nonce, and request details.

Authorization: Digest username="admin", realm="admin@example.re", nonce="7ypf/xlj9XXwfDPEoM4URrv", uri="/admin/settings", response="6629fae49393a05397450978507c4ef1", qop=auth, nc=00000001, cnonce="0a4f113b"

Digest authentication supports SHA-256 as the hashing algorithm. After successful authentication, the server returns an Authentication-Info header with parameters like nextnonce for nonce rotation and rspauth for mutual verification.

Negotiate

Negotiate authentication initiates SPNEGO-based authentication, typically backed by Kerberos or NTLM. This scheme is common in enterprise environments with Active Directory integration. The scheme carries a Base64-encoded SPNEGO token during the negotiation exchange.

Authorization: Negotiate YIIJvwYGKwYBBQUC...

DPoP

DPoP (Demonstrating Proof of Possession) is an OAuth 2.0 extension cryptographically binding access tokens to the client requesting them. The client generates a key pair, includes a signed proof JWT in a DPoP request header, and sends the token with the DPoP scheme instead of Bearer.

Authorization: DPoP eyJhbGciOiJFUzI1NiIs...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6...

DPoP prevents stolen tokens from being used by a different client, addressing a key weakness of standard Bearer tokens.

Other registered schemes

The IANA registry includes additional schemes:

• HOBA uses digital signatures bound to the HTTP origin, eliminating passwords entirely. Experimental status.
• Mutual provides mutual authentication where both client and server verify each other's identity using password-based cryptography. Experimental status.
• SCRAM-SHA-1 / SCRAM-SHA-256 adapt the SCRAM mechanism from SASL to HTTP.
• PrivateToken carries Privacy Pass tokens for anonymous authentication.
• GNAP is the Grant Negotiation and Authorization Protocol scheme.
• vapid authenticates push service requests for Web Push.

Proxy authentication

The authentication framework extends to proxy servers with a parallel set of headers and status codes. When a proxy requires credentials, the flow mirrors origin server authentication with different header names and a 407 status code.

Step	Origin server	Proxy
Challenge status	401	407
Challenge header	WWW-Authenticate	Proxy-Authenticate
Credentials header	Authorization	Proxy-Authorization

A request passing through an authenticating proxy and reaching a protected origin server carries both Proxy-Authorization (for the proxy) and Authorization (for the origin server).

OAuth 2.0

OAuth 2.0 is an authorization framework widely used for delegated access. Rather than sharing credentials directly, a client obtains an access token from an authorization server and presents the token using the Bearer scheme.

The OAuth 2.0 flow involves three parties: the resource owner (end user), the client (application), and the authorization server. The client redirects the user to the authorization server, the user grants permission, and the authorization server issues an access token. The client uses the token to access the resource server.

defines how OAuth tokens are carried in the Authorization header. DPoP adds proof-of-possession binding to prevent token theft.

API key authentication

Many APIs use API keys passed in custom headers (such as X-API-Key) or as query parameters. This approach is not part of the formal HTTP authentication framework and does not use the WWW-Authenticate / Authorization header exchange.

GET /api/data HTTP/1.1
Host: api.example.re
X-API-Key: ak_live_7f3a9b2c4d5e6f1a8b

API keys identify the calling application rather than a specific user. They are common for server-to-server communication and rate-limiting purposes.

Invalid credentials and access denial

When a client fails to authenticate, the server responds with 401. When credentials are valid but the account lacks permission for the requested resource, the server responds with 403.

Some servers respond with 404 instead of 403 to avoid revealing the existence of a protected resource. This pattern is common on platforms where resource enumeration is a security concern.

Credentials in URLs

The URI syntax allows a userinfo component in the authority section.

https://username:password@www.example.re

Example

A client requests a protected resource. The server responds with 401 and challenges with both Basic and Negotiate schemes. The realm parameter identifies the protection space as "Production".

Initial request

GET /reports HTTP/1.1
Host: www.example.re

Server challenge

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="Production"

The client authenticates using the Basic scheme. Decoding dXNlcjpzZWNyZXQxMjM= reveals user:secret123.

Authenticated request

GET /reports HTTP/1.1
Host: www.example.re
Authorization: Basic dXNlcjpzZWNyZXQxMjM=

Successful response

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 4821

Takeaway

HTTP authentication is a challenge-response framework where servers declare accepted schemes through WWW-Authenticate and clients supply credentials in Authorization. The framework supports schemes ranging from simple Basic encoding to token-based Bearer authentication and proof-of-possession mechanisms like DPoP. Proxy authentication follows the same model with Proxy-Authenticate and Proxy-Authorization.

See also

• RFC 9110: HTTP Semantics, Section 11
• IANA HTTP Authentication Scheme Registry
• Authorization
• WWW-Authenticate
• Proxy-Authenticate
• Proxy-Authorization
• Authentication-Info
• 401
• 403
• 407
• HTTP headers