Proxy-Authorization

The HTTP Proxy-Authorization request header carries credentials for authenticating a client with a proxy server after a 407 challenge.

Table of Contents

Usage
Directives
- scheme
- credentials
Example
Where the credentials stop
See also

Usage

The Proxy-Authorization header is sent after a proxy returns a 407 status code along with a Proxy-Authenticate challenge. The client constructs credentials matching the requested Authentication scheme and includes them in the Proxy-Authorization header when resubmitting the request.

Once the proxy validates the credentials, the request is forwarded to the destination server. In a proxy chain with cooperative authentication, the proxy may relay the Proxy-Authorization credentials to the next proxy in the chain.

The equivalent header for origin server authentication is Authorization, which responds to a 401 challenge from the WWW-Authenticate header.

Directives

scheme

The scheme value identifies the authentication method being used. The value matches one of the schemes offered in the proxy's Proxy-Authenticate challenge. Common schemes include Basic, Digest, Bearer, and Negotiate.

credentials

The credentials portion follows the scheme name and contains the authentication data. The format depends on the scheme.

For Basic authentication, the credentials are a Base64-encoded username:password pair.

For Digest authentication, the credentials include a username, realm, nonce, uri, and response hash among other parameters.

For Bearer authentication, the credentials consist of an opaque access token.

Example

A client authenticating with the Basic scheme sends a Base64-encoded username and password pair. Decoding dXNlcjpwYXNzd29yZA reveals user:password.

Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA

A Digest authentication response includes the computed hash and the nonce from the proxy's challenge.

Proxy-Authorization: Digest username="admin", realm="proxy@example.re", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/resource", response="6629fae49393a05397450978507c4ef1"

A Bearer token issued by an OAuth authorization server is passed directly as the credential value.

Proxy-Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

Where the credentials stop

Proxy-Authorization is consumed by the first inbound proxy expecting credentials, and everything downstream sees nothing. The clearest case is the CONNECT tunnel: credentials ride on the CONNECT request addressed to the proxy, the proxy switches to blind forwarding after answering, and the origin receives only the encrypted bytes inside the tunnel. Proxy credentials never reach the destination server.

Redirects strip the header. A client automatically following a redirect removes implementation-generated fields, proxy credentials among them, and regenerates values appropriate to the new request.

JavaScript sits outside this exchange entirely. Header names beginning Proxy- are forbidden in fetch() and XMLHttpRequest, so code never sets the value, and a 407 never surfaces as a response either. The browser prompts or fails at the network layer, which is why a proxied request denied authentication appears in the console as a proxy error with an empty response object and a status of 0, rather than as a readable 407.

The browser applies stored proxy credentials regardless of a request's credentials mode, so credentials: "omit" omits cookies and origin Authorization while the proxy leg authenticates normally.