[squid-users] MFA with squid, is it possible?

Amos Jeffries squid3 at treenet.co.nz
Fri Dec 5 07:52:21 UTC 2025


On 04/12/2025 02:31, NgTech LTD wrote:
> I was wondering if it's possible to use 2fa with squid?

Of course.

> If so, how?

As you know, helpers can do anything you can code/script as their 
actions to validate standard HTTP login credentials.

All it takes is a helper that triggers the 2nd-factor query before 
accepting the login.

A classic example of this which is available in all Squid today is the 
SQL_session helper "ACTIVE" mode. In that case the 2nd-factor is the 
prior use of some specific URL.

A more modern example is OAuth Bearer authentication. Though this 
requires patching of Squid since the feature is not yet passed official 
review.

A somewhat unconventional approach prior to Bearer invention was/is to 
use HTTP Basic auth where the password is a temporary token (or Digest 
auth with a single-use nonce) that can only validate when used on a POST 
with some 2nd-factor details in the request message content. Whereupon 
the user:pass details are changed to something else.


> The authentication of squid is based on a couple methods, but, by what I 
> can identify the 2fa? Is there any option to use some kind of token 
> which can be acquired via some external authentication service?

2FA is pretty much the definition of a how captured-portal logins work. 
So yes, or course.

Modern Squid are configured with "auth_param ... key_extras" in 
squid.conf to pass arbitrary 2FA details to the helper. These can be 
user-provided such as 2FA tokens, or something implicit like client IP 
or Set-Cookie headers.


> I am unsure if it's doable or not.
> I have seen a couple VPN services which offer 2fa, but all of these have 
> connection based authentication.

Nod. VPN are typically connection-oriented designs. It is way easier to 
tie tracking of whole sessions to something persistent like TCP socket 
or src-IP, than to juggle 2FA on a per-message basis.


> The issue with a proxy connection is that the client-to-service 
> connection is in plain text.

As others have mentioned, Squid is perfectly capable of receiving 
encrypted traffic directly from any agent.

The misconception comes from Browsers historically lacking the ability 
to use encrypted proxies. Which is entirely a Browser issue, not a 
property of Squid.


Cheers
Amos


More information about the squid-users mailing list