HTTP provides a simple challenge-response authentication mechanism
which may be used by a server to challenge a client request and by a
client to provide authentication information. It uses an extensible,
case-insensitive token to identify the authentication scheme,
followed by a comma-separated list of attribute-value pairs which
carry the parameters necessary for achieving authentication via that
scheme.
The 401 (unauthorized) response message is used by an origin server
to challenge the authorization of a user agent. This response must
include a WWW-Authenticate header field containing at least one
challenge applicable to the requested resource.
The realm attribute (case-insensitive) is required for all
authentication schemes which issue a challenge. The realm value
(case-sensitive), in combination with the canonical root URL of the
server being accessed, defines the protection space. These realms
allow the protected resources on a server to be partitioned into a
set of protection spaces, each with its own authentication scheme
and/or authorization database. The realm value is a string, generally
assigned by the origin server, which may have additional semantics
specific to the authentication scheme.
A user agent that wishes to authenticate itself with a server--
usually, but not necessarily, after receiving a 401 response--may do
so by including an Authorization header field with the request. The
Authorization field value consists of credentials containing the
authentication information of the user agent for the realm of the
resource being requested.
The domain over which credentials can be automatically applied by a
user agent is determined by the protection space. If a prior request
has been authorized, the same credentials may be reused for all other
requests within that protection space for a period of time determined
by the authentication scheme, parameters, and/or user preference.
Unless otherwise defined by the authentication scheme, a single
protection space cannot extend outside the scope of its server.
If the server does not wish to accept the credentials sent with a
request, it should return a 403 (forbidden) response.
The HTTP protocol does not restrict applications to this simple
challenge-response mechanism for access authentication. Additional
mechanisms may be used, such as encryption at the transport level or
via message encapsulation, and with additional header fields
specifying authentication information. However, these additional
mechanisms are not defined by this specification.
Proxies must be completely transparent regarding user agent
authentication. That is, they must forward the WWW-Authenticate and
Authorization headers untouched, and must not cache the response to a
request containing Authorization. HTTP/1.0 does not provide a means
for a client to be authenticated with a proxy.