[EvanAnderson]

That's great when you have control of your applications. For most corporate IT you're stuck with COTS applications and whatever their built-in auth functionality is. Sure, you can probably bolt a reverse proxy in front (if you're lucky enough for it to be a web app and not a thick native code client) but you get to argue with the vendor when they refuse support because you're not using their recommended configuration.

802.1x certificate-based authentication at layer 2 is a good defense in depth strategy.

[lima]

Even if you can't authenticate at the application level, it's still much better to encrypt/authenticate traffic on the wire (using a VPN or something like Tailscale) instead of 802.1x auth.

[EvanAnderson]

How is an overlay network "much better" (or meaningfully different) than a device-based certificate and 802.1x when the user is accessing an application delivered over HTTPS using a publicly-verifiable certificate authenticating via SAML w/ MFA (Entra ID)? The source subnet attests successful device authentication in the 802.1x example but that's irrelevant beyond, perhaps, a firewall granting access for the device to terminate a TCP connection to the server's TCP port 443. That's no different than the request coming to the server from an authenticated overlay network, to my eye.

I guess if you want to tie the network layer authentication to the user make it 802.1x with a user certificate. Either way you know the request is coming from authenticated endpoint and the user still authenticates to the application independent of the network layer. In all cases HTTPS protects the traffic from MiTM end-to-end.

[lokar]

Use envoy or some other reverse proxy and do per-app auth there