HTTP defines both 401 Unauthorized with WWW-Authenticate and 407 Proxy Authentication Required with Proxy-Authenticate. What is the difference, and which request header answers each?

## Two hops, one mechanism RFC 9110 splits authentication by *who is asking*. The framework, the grammar, and the scheme registry are shared; only the header names and the status code change. | Asking party | Status | Challenge header | Credential header | Scope | |---|---|---|---|---| | Origin server (or reverse proxy speaking for it) | 401 | `WWW-Authenticate` | `Authorization` | end-to-end | | Intermediary the client connects through | 407 | `Proxy-Authenticate` | `Proxy-Authorization` | hop-by-hop | ## Why 'hop-by-hop' is the whole point `Authorization` is addressed to the resource owner. Intermediaries forward it unchanged, which is exactly why a shared cache must not reuse such a response for a different user, and why leaking `Authorization` across a redirect to another host is a real credential-disclosure bug (well-behaved clients drop it on cross-origin redirects). `Proxy-Authorization` is addressed to the immediate next hop only. That proxy validates it and **removes it before forwarding**; if it passed it on, the corporate proxy password would arrive at the origin. Chained proxies each challenge for themselves. The same hop-by-hop rule is why these fields must never be cached or replayed upstream. ## Where you actually meet 407 - A laptop configured with a corporate forward proxy: the very first request returns `407 Proxy Authentication Required` with something like `Proxy-Authenticate: Negotiate` or `Basic realm="corp-proxy"`. - `CONNECT` tunnels for HTTPS: the client authenticates to the proxy on the CONNECT request itself, because once the TLS tunnel is up the proxy can no longer read or inject headers. This is why proxy auth for HTTPS is a `Proxy-Authorization` on CONNECT, and why a proxy that only supports 407 on plain HTTP breaks TLS traffic. - Tooling: `curl --proxy-user`, `HTTPS_PROXY` credentials, JVM `http.proxyUser` — all of these fill `Proxy-Authorization`, not `Authorization`. Mixing them up is a classic wasted afternoon. ## Reverse proxies do not use 407 A CDN, API gateway, ingress controller or load balancer in front of your service is a **reverse** proxy: to the client it *is* the origin. When it enforces auth it must return **401 with WWW-Authenticate**. Returning 407 there tells the client "go authenticate to your local proxy", which the client cannot act on and which some clients report as a network-configuration error. This distinction is the point of the question in most interviews. ## Both at once Nothing forbids being challenged by both: a request may carry `Proxy-Authorization: Basic ...` for the egress proxy and `Authorization: Bearer ...` for the API. The proxy strips the first and forwards the second. If your gateway logs headers, note that both are secrets and both belong on a redaction list. ## Diagnostics - Client reports 407 but you never deployed a proxy: the client environment has one (`HTTP_PROXY`, PAC file, corporate MDM). Nothing on your side can fix it. - Credentials sent as `Authorization` are ignored and the 407 repeats: wrong header — the proxy only reads `Proxy-Authorization`. - Auth works over HTTP but not HTTPS through the same proxy: the proxy is not handling authentication on `CONNECT`. - 407 responses that lack `Proxy-Authenticate` are as broken as 401s that lack `WWW-Authenticate`; the client cannot know which scheme to attempt. ## Status-code hygiene Both codes mean *unauthenticated at that hop*. Neither means "authenticated but not permitted" — that is 403 for the origin. And a proxy that refuses an authenticated client for policy reasons returns 403 too, not a repeated 407.