HTTP/1.1, part 7: Authentication

This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity.

A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--does so by including an Authorization request-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.

Authorization = "Authorization" ":" credentials HTTP access authentication is described in "HTTP Authentication: Basic and Digest Access Authentication" . If a request is authenticated and a realm specified, the same credentials &SHOULD; be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks). When a shared cache (see &shared-and-non-shared-caches;) receives a request containing an Authorization field, it &MUST-NOT; return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds: If the response includes the "s-maxage" cache-control directive, the cache &MAY; use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache &MUST; first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request. (This is the defined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy &MUST; always revalidate it before re-using it. If the response includes the "must-revalidate" cache-control directive, the cache &MAY; use that response in replying to a subsequent request. But if the response is stale, all caches &MUST; first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request. If the response includes the "public" cache-control directive, it &MAY; be returned in reply to any subsequent request.

The Proxy-Authenticate response-header field &MUST; be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI.

Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" . Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection and &SHOULD-NOT; be passed on to downstream clients. However, an intermediate proxy might need to obtain its own credentials by requesting them from the downstream client, which in some circumstances will appear as if the proxy is forwarding the Proxy-Authenticate header field.

The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy which requires authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested.

Proxy-Authorization = "Proxy-Authorization" ":" credentials The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" . Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy that was expecting to receive credentials. A proxy &MAY; relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

The WWW-Authenticate response-header field &MUST; be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.

WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" . User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters.

This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does make some suggestions for reducing security risks.

Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1. does not provide a method for a server to direct clients to discard these cached credentials. This is a significant defect that requires further extensions to HTTP. Circumstances under which credential caching can interfere with the application's security model include but are not limited to: Clients which have been idle for an extended period following which the server might wish to cause the client to reprompt the user for credentials. Applications which include a session termination indication (such as a `logout' or `commit' button on a page) after which the server side of the application `knows' that there is no further reason for the client to retain the credentials. This is currently under separate study. There are a number of work-arounds to parts of this problem, and we encourage the use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent in this problem. In particular, user agents which cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control.