Proxy Authentication

How a proxy asks a client to prove who it is before forwarding the request, and what that looks like in practice.

The basics

When a client sends a request through a proxy, the proxy can stop it and reply with a 407 Proxy Authentication Required. The response carries a Proxy-Authenticate header that names the scheme (Basic, Bearer, NTLM, ...) and a realm. The client then retries the same request with a Proxy-Authorization header, and the proxy forwards it if the credentials check out.

GET / HTTP/1.1
Host: example.com

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="corp-proxy"

GET / HTTP/1.1
Host: example.com
Proxy-Authorization: Basic Zm9vOmJhcg==

HTTP/1.1 200 OK

Note this is separate from origin authentication: 401 and Authorization deal with the destination server, while 407 and Proxy-Authorization deal with the proxy itself. Both can appear in the same exchange.

Common schemes

• Basic — username and password, base64-encoded. Only sensible over TLS.
• digest — challenge/response; the password is never sent. Mostly legacy.
• negotiate / Kerberos — ticket-based single sign-on, common in Windows networks.
• Bearer — a short-lived token (OAuth 2.0, JWT). The usual choice for machines and CI.

Configuring a client

Most tools read the proxy and its credentials from environment variables:

export https_proxy="http://corp-proxy.example:8080"
export no_proxy=".example.com,localhost"

With curl you pass credentials separately, so they don't end up in the URL or shell history:

curl -x http://corp-proxy.example:8080 -u alice:secret https://example.com/

Keeping it safe

• Use TLS on the connection to the proxy; otherwise the password travels in clear.
• Prefer tokens over long-lived passwords for anything automated — tokens can be scoped and revoked.
• Log the authenticated identity, never the Proxy-Authorization header.
• Don't embed credentials in URLs; they leak into logs, history, and error messages.

---