Squid Interception vs Explicit Proxy Authentication
Explain why ordinary explicit proxy authentication cannot simply be added to a Squid interception listener.
An explicit proxy client knows it is talking to a proxy. An intercepted browser thinks it connected to the website. That difference is central to authentication.
Normal proxy authentication uses a proxy challenge and a proxy authorization response. A client that did not select a proxy should not casually send proxy credentials to an unexpected intermediary.
Squid's interception guidance therefore does not support simply combining proxy_auth with interception mode. A working Basic authentication helper does not change what the browser believes the remote endpoint is.
If identified users need a normal authenticated forward proxy, configure the clients explicitly, directly or through an appropriate managed proxy configuration. Keep that listener and its authentication policy distinct from an interception listener.
An authentication portal, network-level identity system, or TLS interception arrangement is another design with different trust and deployment requirements. It is not a one-line repair for the missing explicit-proxy exchange.
Do not solve the absence of a prompt by making the intercepted service public or allowing every client. First decide whether the requirement is explicit user authentication or interception of traffic that was never configured for a proxy. They need different assumptions.