10. Access Authentication

HTTP provides a simple challenge-response authorization mechanism which may be used by a server to challenge a client request and by a client to provide authentication information. The mechanism uses an extensible 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.

auth-scheme	=	"Basic" | token
auth-param	=	token "=" quoted-string

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 the challenge applicable to the requested resource.

challenge	=	auth-scheme 1*LWS realm [ "," 1#auth-param ]
realm	=	"Realm" "=" quoted-string

The realm attribute is required for all access authentication schemes which issue a challenge. The realm value, in combination with the root URL of the server being accessed, defines the authorization space. These realms allow the protected resources on a server to be partitioned into a set of authorization spaces, each with its own authentication scheme and/or 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.

credentials	=	auth-scheme [ 1*LWS encoded-cookie ] #auth-param
encoded-cookie	=	1*<any CHAR except CTLs or tspecials,
		   but including "=" and "/">

The domain over which credentials can be automatically applied by a user agent is determined by the authorization space. If a request is authenticated, the credentials can be reused for all other requests within that authorization space for a period of time determined by the authentication scheme, parameters, and/or user preference.

The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional mechanisms may be used at the transport level, via message encapsulation, and/or 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 access authentication. That is, they must forward the WWW-Authenticate and Authorization headers untouched. HTTP/1.0 does not provide a means for a client to be authenticated with a proxy -- this feature will be available in future versions of HTTP.

Note
The names Proxy-Authenticate and Proxy-Authorization have been suggested as headers, analogous to WWW-Authenticate and Authorization, but applying only to the immediate connection with a proxy.

10.1 - Basic Authentication Scheme

T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen - 12 MAR 95

[Next] [Previous] [Top] [Full Contents] [Search]

Generated with CERN WebMaker